oid4vc-haip-sd-jwt-vc
oid4vc-haip-sd-jwt-vc copied to clipboard
openid
what is revocation/status management mechanism
- the Token Status List draft RFC: https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/ .
- another proposal: https://c2bo.github.io/draft-bormann-identifier-list/draft-bormann-identifier-list.html
should take into account requirement VCR_09 in ARF:
"The Commission SHALL create or reference technical specifications providing all necessary details for PID Providers, Attestation Providers, and Wallet Providers to implement an Attestation Status List mechanism and/or an Attestation Revocation List mechanism for the PIDs, attestations and WIAs they issue. These technical specifications SHALL also contain all details necessary for Relying Party Instances and Relying Parties to use these mechanisms to verify the revocation status of PIDs, attestations, and WIAs."
https://openid.github.io/oid4vc-haip/openid4vc-high-assurance-interoperability-profile-wg-draft.html#section-7 recommends the use of https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/ and the status claim in SD-JWT VC.
I believe that is sufficient now given I believe relying parties will no longer receive WIAs so we don't need to solve that part? Hence marking as pending close.
what about key attestation? do we need to say that when key attestation as defined in annex D of VCI is used, status claim and ietf draft are mandatory?
Hmm, good question, maybe. I'm not clear if Key Attestations are actually in scope for the ARF statement you quote?
Reading it again I think we need to make a similar statement about Wallet Attestations
I'm not sure have status lists for those two things is really a HAIP level MUST though? I can see other ecosystems being happy for those things to just live on until their natural expiry as they presumably won't have lifetimes as long as actual VCs will?
WG discussion, add a non-normative note that points to 18013-5 rev2 draft that includes revocation mechanism for mdocs.