Rick Byers

Sounded like maybe `requestClaims` had the most support - let's go with that unless someone makes a stronger argument in the next two weeks?

> The problem of over requesting is at the protocol layer, not at the request API. We can call it whatever, but the problem is that you can still do:...

Closing is fine with me.

FWIW using intentional friction to reduce the likelihood of abuse is exactly the direction I've proposed for Chrome's implementation. I imagine some way of computing a risk score (eg. anonymous...

If the DC API spec is going to [require request validation](https://github.com/WICG/digital-credentials/issues/152) then perhaps the OpenID4VP spec needs to be clear about which validation rules are appropriate to apply at the...

I think we need to work with the protocols to ensure there is clarity about which validation rules are enforced where in the stack. We've [heard from EUDI designers](https://github.com/WICG/digital-credentials/issues/100#issuecomment-2058975502) that...

From discussion in the call today, we (Android/Chrome) are arguing that these two cases must be indistinguishable (consistent with WebAuthn): - User declines to share a credential they have which...

Hmm, I'm not sure if #156 helps or hurts actually. Is it implicit that all such validation rules must be stateless (not influenced by the contents of the user's wallet)?...

This is certainly interesting to me, but the details really matter here. I'm OK imposing some burden on adoption, but it's got to be a bar that many would already...

Ah that's great, thanks Mike! I didn't realize this had gotten that far along. I can point our potential customers at [strict CSP](https://web.dev/articles/strict-csp) and [trusted types](https://web.dev/articles/trusted-types) and get their feedback...