Dave Longley

The security considerations should indicate at least two things to help verifiers mitigate problems here: 1. Advise verifiers not to accept a status list VC that is outside of its...

Another option is: 1. wallet requests credentials (VCI) 2. issuer responds with a 400 error code with JSON including a `presentation_required` error and a presentation request (this is the same...

> "When making the API call, the website should not learn anything about the user's credentials or wallets unless the user agent has gained explicit user consent. Likewise wallet applications...

> for presentation, the trust model is such that if the verifier trusts the signature/MAC of the issuer on the credential, it also trusts that the issuer have checked that...

A significant consideration should be what advice to give to verifiers (aka relying parties) who want to support or continue supporting accepting credentials from Web Wallets ... if the new...

> Makes sense. Even if the new API supports web wallets out of the gate, I'm sure we're going to see inconsistent uptake of the new api from wallets of...

> In the case of `IdentityCredential` as "a more specific verifiable credential type"... is "IdentityCredential" also an RDF Class (yes)... is it a web-exposed name? I suspect this is backwards...

Also supported if the issuer constructs more than one credential (atomizes them as needed) to enable the holder to selectively disclose (where the selection choices are up to the options...

@Sakurann, > do you need a mechanism for key attestation that is being discussed in this issue for ldp_vc proof type as well? Hmm, I would expect that either the...

@Sakurann, > @dlongley what is a mechanism in ldp_vc that is equivalent to a JWT header? I think all we need to say is that for ldp_vc, put key attestation...