Rick Byers

Agreed we should explore APIs with a single bit of privacy impact. Another option is "has this user ever presented a digital credential before". This is probably sensitive right now...

From meeting discussion this evening: updating the issue title to reflect the problem rather than just one possible solution. We've heard from multiple potential verifiers that it's important to them...

Agreed, and it's been part of Chrome plans from the start, though framed as [enabling competition and choice in credential formats](https://docs.google.com/presentation/d/1mz7AUJLc9y7zOU7CfLCsBSt3dGIkN_x61tpoRaQCQko/edit?resourcekey=0-NhvH5WIUclnZZPyRSyyLqQ#slide=id.g27f155581c9_0_10). I've tried to capture this more explicitly in a...

FWIW , on the one hand I think there's a good argument for saying this is the wrong layer of the stack to make such a requirement. Just like with,...

One note from the call today, it sounded like there was no disagreement with at least having a statement in our spec along the forms of "implementations which pass PII...

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...

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...

To be consistent with [other permission policy names](https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md) like `publickey-credentials-get` and `identity-credential-get`, @samuelgoto suggests we use the name `digital-credential-get` and I agree.

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

Agreed. Customers may have activation-less use cases (eg. click a button on one page that redirects to a different page where asking again would feel redundant). But I think we...