This is spec is probably written with the assumption that Permission Delegation <https://docs.google.com/document/d/1x5QejvpyQ71LPWhMLsaM1lWCfSsBsSQ8Dap9kJ6uLv0/edit?usp=sharing> 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.
For example, a browser without Permission Delegation would require permission prompt from iframe (which contains origin of iframe in the prompt) in order to use any permission-based API. Permission Policy or allow attribute are just there to allow permission request from iframes, but that doesn't necessary mean that permission is delegated directly to iframe. If you try to ship Capability Delegation API in above model, this would be a bypass of permission prompt or delegating permission to cross-origin iframes without user's knowledge. Thanks, Jun On Monday, July 12, 2021 at 9:31:24 AM UTC-7 Mustaq Ahmed wrote: > A few quick updates: > - The WICG/capability-delegation > <https://github.com/WICG/capability-delegation> repository is the current > home for the explainer and a spec draft > <https://wicg.github.io/capability-delegation/spec.html>. > - Please use a new/existing issue > <https://github.com/WICG/capability-delegation/issues> for any comments > or suggestions. > - We filed a TAG review request > <https://github.com/w3ctag/design-reviews/issues/655> two weeks ago. > > > > On Wed, Nov 18, 2020 at 5:01 PM Mustaq Ahmed <mus...@google.com> wrote: > >> Hi Daniel: >> >> Sorry for the delay, thanks for listing those concerns. >> >> I have added a Privacy and security considerations >> <https://docs.google.com/document/d/1IYN0mVy7yi4Afnm2Y0uda0JH8L2KwLgaBqsMVLMYXtk/edit#heading=h.feeez0mmlqam> >> section >> in the design doc to address three of the concerns, please take a look and >> let us know if we missed anything. I haven't yet replied to the Spectre >> point, I need to fully understand the attack vector you are thinking of. >> >> The relation to Feature/Permission Policy is still an open question, we >> will need some time to answer this. >> >> Mustaq >> >> >> On Fri, Nov 6, 2020 at 12:04 PM Daniel Vogelheim <voge...@chromium.org> >> wrote: >> >>> Hello Mustaq, >>> >>> We've discussed your intent within security + privacy teams. The >>> discussion raised a number of concerns, but we couldn't find enough detail >>> to either substantiate or allay them. This unfortunately makes it difficult >>> to give you actionable feedback. >>> >>> Our thoughts: This API effectively packages a permission / user >>> interaction in a token and allows it to be sent somewhere else, creating a >>> permission-capability-thing. This raises a number of questions: >>> >>> - The idea of gating functionality on user interaction is to make sure >>> that the user understands what they are interacting with. If a user >>> interaction is 'packaged' and sent for consumption elsewhere, does this >>> still hold? Could a malicious user put the 'packaged' interaction to a >>> surprising use? >>> - Are there limits to where it can be passed to? Could it be passed - >>> via a server round-trip - to another site running in the same browser? >>> - Is there any info on the API that would consume the token? >>> - The token is unspecified, but seems to follow the pattern of >>> 'unguessable secret number'. The problem here is with the Spectre attack >>> family, where we've had to change our assumption to assume that any data >>> within a process is potentially readable, even by sandboxed code. Under >>> this assumption, could the token be read by an unintended recipient? >>> >>> We were also a bit unclear on the use cases, and the relationship to >>> feature policy. >>> >>> Mustaq, could you maybe update the docs to include this type of >>> information? We'd like to take a second look at it. >>> >>> Thanks, >>> Daniel >>> >>> >>> On Fri, Oct 23, 2020 at 5:26 PM Mustaq Ahmed <mus...@chromium.org> >>> wrote: >>> >>>> Contact emailsmus...@chromium.org >>>> >>>> Explainergithub.com/mustaqahmed/capability-delegation >>>> >>>> SpecificationNone >>>> >>>> Summary >>>> >>>> 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). >>>> >>>> Blink componentBlink >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink> >>>> >>>> Motivation >>>> >>>> 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. >>>> >>>> Initial public proposal >>>> https://discourse.wicg.io/t/capability-delegation/4821 >>>> >>>> TAG reviewNone (haven't started yet). >>>> >>>> Risks >>>> Interoperability and Compatibility >>>> >>>> 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. >>>> >>>> >>>> Gecko: No signal >>>> WebKit: No signal >>>> Web developers: Positive (comment >>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=928838#c22> on >>>> Web Payments) >>>> >>>> Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, Chrome OS, Android, and Android WebView)?Yes >>>> >>>> >>>> Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>> ?No (not yet) >>>> >>>> Tracking bughttps://crbug.com/1130558 >>>> >>>> Link to entry on the Chrome Platform Status >>>> https://www.chromestatus.com/feature/5708770829139968 >>>> >>>> -- >>>> 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 >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO4GMjCbfO7gWS%3DgsGU2LvYkG%3D15Ggv88RQqivFFdv65Vg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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+unsubscr...@chromium.org. 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.
