Dan: 8 days ago work going on on the spec

Ken: payment integration...

Sangwhan: I see what they're trying to solve, this makes sense. Doesn't seem compatible with.... the capability delegation protocol and capabilities should probably be aligned with what we have in permission policy

Ken: yeah, what capabilities is this going to apply to?

Sangwhan: right now it's payment request

Ken: and fullscreen

Sangwhan: it's in the example and they've been thinking about it but current origin trial is just for payment request. The use case is fine. Seems a little bit unaligned with permission policy. It should be delegating a permission based on a user activation and request? If you're delegating an iframe to be able to do getusermedia based on the parent being granted getusermedia... should that be possible or should that be a separate permission? if you do getusermedia request on an iframe you're going to get a permission request on a different origin than what the user is looking at.. that's weird.

Dan: i was tracking down multi implementer support angle.. Chrome status page says positive feedback from Mozilla but when I followed that link it goes to a mozilla standards position where Anne says "I'm not 100% sure I understand this correctly" but does say agree it seems useful... but I think this is more.. positive engagement.

Sangwhan: not affirmative

Dan: yeah

Sangwhan: a bunch of unanswered questions, the fact that user activiation doesn't pass through iframes correctly at least from a scripting perspective is problematic. it is a user activation but in certain cases it doesn't work from an end user perpsective which is confusing. User activation gating is our problem not their problem as an end user. i have to think about this more. I can see the utility, definitely. There's a problem that needs to be solved, just don't know if the proposed api is the right way to approach it.

Dan: leaves comment. Come back to it at plenary.

Peter: this one we're happy with.

Rossen: right. here the thing is you want to be able to grab a capability and propogate it down to an iframe... the way you do this is for any nested iframe you can request to have a capability delegated. For example giving it the ability to handle payments. Making e.g. Stripe work in an iframe as a payment handler. Removing friction in payment is a key factor. Great use case. This delegates down feature capabilities. All the privacy control features as part of webappsec permissions policy. Feature wise it makes sense. By delegating the capability you delegate it to anything inside that iframe. They can further delegate it to someone else. Don't know if it's preventable. The other thing that jumped out: as you read their doc - the privacy & security section - they're claiming that the capability doesn't allow provisions to sensors. Not true - it does allow camera, gyroscope, etc... you can delegate device access through that feature. I've asked them to document that in their security & privacy section.

Peter: some background - the capabilities includes the user activation state... they did delegate the capability of user activation... that way we're not baking in the user activation.

Hadley: what's the difference?

Peter: not just the permission. some things require user activation. You could delegate the permission but not have the user activation state. becuase the parent frame got the user activation state.

Hadley: is it possible for a webapp with access to camera and microphone and had an iframe for advertisers - is it possible the advertiser would get access without me being aware?

Rossen: yes although they could that today....

Dan: some possibility here - getusermedia for example in a peer to peer webrtc session..

Peter: we could restrict the capability to delegate to a subset of capabilities.

Rossen: i would be more worried about webusb or webshare...

Peter: parent frame... Payment processing...

Rossen: the exploit path is to impersonate myfavstore.com - i fool you into thinking you're buying a new headset. ... if I already fooled you on the top level document if I give it to a subframe it doesn't really matter. The payment capability is decent. the scenario is defendable. When it comes to device capability we need to tighten down. Maybe we can tighten the allow list to only a subset of what's listed in permissions policy.

Dan: i think that makes sense - don't open the floodgates to all the capabilities...

Hadley: i second that.

Rossen: I like that. In that case my proposal is to keep the issue open and feed that back and see if they're ok with that.

Peter: their explainer mentions a few use cases - i don't think they want to expose everything.

Rossen: it's in the spec itself. in Section 3.

Hadley: Adding that comment sounds good to me.