Do we need a permissions policy for third-party frames?

[pkotwicz]

The digital identity draft - https://wicg.github.io/digital-identities/ - does not specify whether the digital identity API should be callable from an <iframe>

Should there be a digital-identity-specific permission policy - <iframe allow=""> which enables a toplevel frame to grant an <iframe> the ability to make a digital identity request?

[timcappalli]

There is some level of precedent for this from WebAuthn:

• https://w3c.github.io/webauthn/#sctn-iframe-guidance
• https://w3c.github.io/webauthn/#sctn-seccons-visibility

This is also another reason to consider a clientData equivalent to include things like cross-origin boolean and origin value vs topOrigin value (ref: w3c/webauthn#1891). (Other uses include TLS context, request type,

[RByers]

Oh definitely our intent was not to have it available by default (we discussed that somewhere, thanks for catching it wasn't in the spec yet). I personally always assumed that we'd need the permission policy for it, but I'm guessing it's not urgent so I'd be happy to wait until we have a legitimate case that needs it before proposing spec'ing it (where I assume we will have a utility vs. privacy risk debate).

[marcoscaceres]

Agree... at the same time, we need to explicitly forbid access to get() beyond the "top-level navigable"... let's start with that.

Noting (and not that it matter too much) that CredMan doesn't have a permission policy, but talks about potential issues with allowing this in iframes:
https://www.w3.org/TR/credential-management-1/#security-origin-confusion

So, we might not ever allow it either.

[ryanhargrove]

I have a real use case for this! While working through an integration, I got the exception:

Failed to execute 'get' on 'CredentialsContainer': The digital identity credential can only be requested in a document which is same-origin with all of its ancestors.

My use case is something like:

---

• profile.mycompany.com shows a users profile information
• verifier.mycompany.com can request and verify a digital credential

---

• profile.mycompany.com should be able to embed verifier.mycompany.com in an iframe and use it to verify a digital credential on their behalf. The iframed page should be the one calling the Digital Credentials API
• The user should see profile.mycompany.com in the credential presentation half sheet. It could be confusing to the user to not see the top level domain that they are on asking for their digital credential

---

To me, the suggestion in #78 (comment) makes sense, as the toplevel frame would know which child iframe to trust to make a credential request.

I dont see this use case as much different than a website using an JS file to accept payments (like <script src="https://js.stripe.com/></script>)

[RByers]

Thanks Ryan, and agreed! Using an iframe like this is IMHO a strict security improvement over putting it all in the main frame. Of course you could use a simple RPC script in the main frame which communicates via postMessage to the subframe to implement this yourself without a permission policy, but that's silly and adds to the attack surface area. So I think we should just do the permission policy to prevent people from either building such RPC systems or hoisting all the code to the main frame.

[RByers]

To be consistent with other permission policy names like publickey-credentials-get and identity-credential-get, @samuelgoto suggests we use the name digital-credential-get and I agree.

[RByers]

Discussed in the meeting today we should also convey both the top and sub-frame origin in client-data (#95)

[marcoscaceres]

Ok, we need to have the spec pass along the iframe's origin or something... we need to look at what Web Authn does?

[samuelgoto]

To be consistent with other permission policy names like publickey-credentials-get and identity-credential-get, @samuelgoto suggests we use the name digital-credential-get and I agree.

I still think we should try to be consistent with WebAuthn and FedCM, but just for transparency, I just realized that WebOTP picked - unfortunately - a slight variation: otp-credentials (without the -get suffix):

https://wicg.github.io/web-otp/#sctn-permissions-policy