Capability delegation means allowing a frame to relinquish its ability to call a restricted API and transfer the ability to another (sub)frame it can trust. If an app wants to delegate its ability to call a restricted JS capability (e.g. popups, fullscreen, etc) to a known+trusted third-party frame, the app would utilize a Capability Delegation API to "transfer" the ability to the target frame in a time-constrained manner (unlike static mechanisms like <iframe allow> attributes).
Here are some practical scenarios that would utilize a capability delegation mechanism.
- Many merchant websites host their online store on their own domain but outsource the payment collection and processing infrastructure to a Payment Service Provider (PSP) to comply with security and regulatory complexities around card payments. This workflow is implemented as a “pay” button inside the top (merchant) frame where it can blend better with the rest of the merchant’s website, and payment request code inside a cross-origin iframe from the PSP. The Payment Request API used by the PSP code is gated by transient user activation (to prevent malicious attempts like unattended or repeated payment requests). Because the top (merchant) frame’s user interaction is not visible to the iframe, the PSP code needs some kind of a delegation in response to a click in the top frame to be able to initiate a payment processing. - A web service that does not care about user location except for a "branch locator" functionality provided by a third-party map-provider app can delegate its own location access capability to the map iframe in a temporary manner (right after the "branch locator" button is clicked).
- An authentication provider may wish to show a popup to complete the authentication flow before returning a token to the host site.
No compat risk as this would be a new feature.
For the interop question, we need to consider this two-phase process:
[A] This intent conceptually covers the general mechanism which would remain unexposed to the Web until we hit the next (capability specific) stage.
[B] Then each capability (e.g. payment request, location access etc) would need spec discussion by corresponding capability owners to define their own post-delegation behavior (what happens to a specific capability after delegation happens).
We plan to implement [A] as the first step (this intent). Then as the second step, we would iterate over [A]+[B] in parallel for a specific capability that has immediate use-cases (e.g. Web Payments). There would perhaps be a new intent for that specific [B]. We expect to have other browser vendors fully on board during the [A]+[B] iteration step.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO4GMjCbfO7gWS%3DgsGU2LvYkG%3D15Ggv88RQqivFFdv65Vg%40mail.gmail.com.
This is spec is probably written with the assumption that Permission Delegation is implemented (or should be implemented) in all browsers. However, Permission Delegation is not a Web Standard, and browsers (and other user agent) are free to implement any sort of permission model.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/784fa5a5-72bd-4e42-8dfb-cdbd8258b8dfn%40chromium.org.