IACA Metadata for Credential Issuers
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 125
- Forks
- 41
- PR merge metrics
- No merged PRs in 30d
Description
This issue proposes an extension to OpenID4VCI Credential Issuer Metadata to publish Issuing Authority Certificate Authority (IACA) certificates. These certificates are defined in ISO 18013-5 (mDL).
A key decision is whether to provide the certificates by value in the Credential Issuer Metadata itself or whether to provide it by reference at a different URI. I propose to provide it by reference so that the timing of updates can be controlled by normal Web Cache-Control directives. (This is the same reason that jwks_uri is used in OpenID Connect OP metadata to provide keys by reference.)
I propose that IANA certificates be provided using this Credential Issuer Metadata element:
mdoc_iacas_uri: OPTIONAL. URL of the Credential Issuer’s IACA set document. This document contains the IACA certificates [ISO 18013-5] the used to validate signatures for issued mDOCs.
The referenced document has this structure:
{"iacas":
[
{"certificate": "base64-encoded DER representation of IACA certificate"},
…
]
}
The top-level structure is intentionally parallel to a JWK Set – which uses a keys element whose value is an array of JWKs. The array elements are structures with a required certificate element, allowing other certificate metadata to be added to the structures, such as expiration time, as needed.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no repository files, tests, or entry points. Start by reviewing the OpenID4VCI Credential Issuer Metadata definition and the 12-comment discussion, then determine whether the proposed metadata element and referenced JSON document are agreed and where they belong in the specification. Done means an accepted, unambiguous metadata extension with corresponding specification changes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- json
- Domain
- api, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100