Thanks for your feedback, Jun. That's an important point that calls for clarification:
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. > We made no such assumption here about Permissions. Our intent is to only define a generic API for delegation here, and to leave any capability-specific details to capability-owners. Any "capability" here could be Permission-gated (like camera and web-usb) or Permission-agnostic (like fullscreen and popup), and the capability-owners will decide, on a case-by-case basis, which Permission model they would like to incorporate, if at all. Having said that, a recent comment in our TAG review issue <https://github.com/w3ctag/design-reviews/issues/655> seems to be suggesting a generalized behavior for capabilities which is not what we intended this for. Let's continue this discussion there for greater visibility. On Wed, Oct 27, 2021 at 3:28 AM 'Jun Kokatsu' via blink-dev < blink-dev@chromium.org> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/784fa5a5-72bd-4e42-8dfb-cdbd8258b8dfn%40chromium.org?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/CAB0cuO5Cs1OQaD-n48tQRNnuG%2BZ-hK1YdeX0mtqh31OXtzW%2BjA%40mail.gmail.com.
