Brian Campbell

https://w3c.github.io/webappsec-dbsc/#format-jwt '25 May 9 Editor’s Draft has the following, with iat and key having erroneous or self-contradictory as string type definitions. 

> Thanks. Just to check: The `jwk` header field is only meant to hold a key for which the JWT itself is signed with, correct? Yes. That's from https://www.rfc-editor.org/rfc/rfc7515#section-4.1.3 >...

I maintain that the `jwk` header parameter would be more appropriate but this in https://github.com/WICG/dbsc/pull/68 is an improvement nonetheless. Thank you.

My comment in https://github.com/WICG/dbsc/issues/44#issuecomment-2320985474 did mention a preference but wasn't meant to ask for this to be reopened, apologies for that. It was more intended to acknowledge and say thanks...

> The model I prefer is that the wallet only needs the verified origin. This likewise seems like the appropriate level/amount of authentication information for a web API to be...

On the layer of the stack point it might be worth the observation that OID4VP (and its nascent profile for this API) allows for but does not require response content...

> It registers them with the OS. LIke - it registers like credential metadata with the OS? Or registers some restricted code that can look at the request and return...

> Given we moved away from the whole "identity" thing, I renamed it to `DigitalCredentialsProvider` instead. That makes more sense in the context of `providers` being an array. > >...

> What if we called it `DigitalCredentialsPresentationRequest`? It is long but a bit better than providers IMO. Agree it's better than providers. Don't know if it's *too* long.

Concur that `IdentityRequestOptions` or `IdentityRequestDetails` would better convey the intent of this thing. I must admit I was somewhat confused reading the [initial spec](https://github.com/WICG/digital-identities/pull/57) by the name of the thing...