Open pkotwicz opened 4 months ago
The digital identity draft - https://wicg.github.io/digital-identities/ - does not specify whether the digital identity API should be callable from an </p> <p>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?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/timcappalli"><img src="https://avatars.githubusercontent.com/u/6476604?v=4" />timcappalli</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <p>There is some level of precedent for this from WebAuthn: </p> <ul> <li><a href="https://w3c.github.io/webauthn/#sctn-iframe-guidance">https://w3c.github.io/webauthn/#sctn-iframe-guidance</a></li> <li><a href="https://w3c.github.io/webauthn/#sctn-seccons-visibility">https://w3c.github.io/webauthn/#sctn-seccons-visibility</a></li> </ul> <p>This is also another reason to consider a <a href="https://w3c.github.io/webauthn/#dictionary-client-data">clientData</a> equivalent to include things like cross-origin boolean and origin value vs topOrigin value (ref: <a href="https://github.com/w3c/webauthn/pull/1891">https://github.com/w3c/webauthn/pull/1891</a>). (Other uses include TLS context, request type, </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/RByers"><img src="https://avatars.githubusercontent.com/u/1280419?v=4" />RByers</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <p>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). </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/marcoscaceres"><img src="https://avatars.githubusercontent.com/u/870154?v=4" />marcoscaceres</a> commented <strong> 4 months ago</strong> </div> <div class="markdown-body"> <p>Agree... at the same time, we need to explicitly forbid access to <code>get()</code> beyond the "top-level navigable"... let's start with that.</p> <p>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: <a href="https://www.w3.org/TR/credential-management-1/#security-origin-confusion">https://www.w3.org/TR/credential-management-1/#security-origin-confusion</a></p> <p>So, we might not ever allow it either. </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/ryanhargrove"><img src="https://avatars.githubusercontent.com/u/156133780?v=4" />ryanhargrove</a> commented <strong> 3 weeks ago</strong> </div> <div class="markdown-body"> <p>I have a real use case for this! While working through an integration, I got the exception:</p> <p><code> 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. </code></p> <p>My use case is something like:</p> <hr /> <ul> <li><code>profile.mycompany.com</code> shows a users profile information</li> <li><code>verifier.mycompany.com</code> can request and verify a digital credential</li> </ul> <hr /> <ul> <li><code>profile.mycompany.com</code> should be able to embed <code>verifier.mycompany.com</code> 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</li> <li>The user should see <code>profile.mycompany.com</code> 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</li> </ul> <hr /> <p>To me, the suggestion in <a href="https://github.com/WICG/digital-credentials/issues/78#issue-2137786327">https://github.com/WICG/digital-credentials/issues/78#issue-2137786327</a> makes sense, as the toplevel frame would know which child iframe to trust to make a credential request. </p> <p>I dont see this use case as much different than a website using an JS file to accept payments (like <code><script src="https://js.stripe.com/></script></code>)</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/RByers"><img src="https://avatars.githubusercontent.com/u/1280419?v=4" />RByers</a> commented <strong> 3 weeks ago</strong> </div> <div class="markdown-body"> <p>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.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/RByers"><img src="https://avatars.githubusercontent.com/u/1280419?v=4" />RByers</a> commented <strong> 2 weeks ago</strong> </div> <div class="markdown-body"> <p>To be consistent with <a href="https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md">other permission policy names</a> like <code>publickey-credentials-get</code> and <code>identity-credential-get</code>, @samuelgoto suggests we use the name <code>digital-credential-get</code> and I agree. </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/RByers"><img src="https://avatars.githubusercontent.com/u/1280419?v=4" />RByers</a> commented <strong> 1 week ago</strong> </div> <div class="markdown-body"> <p>Discussed in the meeting today we should also convey both the top and sub-frame origin in client-data (#95)</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/marcoscaceres"><img src="https://avatars.githubusercontent.com/u/870154?v=4" />marcoscaceres</a> commented <strong> 1 week ago</strong> </div> <div class="markdown-body"> <p>Ok, we need to have the spec pass along the iframe's origin or something... we need to look at what Web Authn does? </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/samuelgoto"><img src="https://avatars.githubusercontent.com/u/693738?v=4" />samuelgoto</a> commented <strong> 1 week ago</strong> </div> <div class="markdown-body"> <blockquote> <p>To be consistent with <a href="https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md">other permission policy names</a> like publickey-credentials-get and identity-credential-get, @samuelgoto suggests we use the name digital-credential-get and I agree.</p> </blockquote> <p>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: <code>otp-credentials</code> (without the <code>-get</code> suffix):</p> <p><a href="https://wicg.github.io/web-otp/#sctn-permissions-policy">https://wicg.github.io/web-otp/#sctn-permissions-policy</a></p> </div> </div> <div class="page-bar-simple"> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>
The digital identity draft - https://wicg.github.io/digital-identities/ - does not specify whether the digital identity API should be callable from an