Repository navigation
Conversation
|
📄 Editor's Copy preview Preview of 2b6b0f3; updated on every push. For review only — the official specifications are published at https://openid.net/specs/ |
Contributor
Author
|
Joseph presented this on today's PR. Oliver & Martijn agreed to review. The CDDL socket syntax wasn't familiar to people on the call and maybe we want to consider other options, but that's editorial and as it is may be more readable to AIs. |
awoie
reviewed
Sep 13, 2026
awoie
reviewed
Sep 13, 2026
awoie
requested changes
Sep 13, 2026
Contributor
|
Furthermore, we might need to create an issue to fix the toolchain (not necessarily in this PR) because the word document numbers the annexes as ordinary clauses, e.g., "13 ISO mdoc Credential Format". |
Contributor
Author
Good point - raised #60 for this, thanks. |
jogu
added a commit
that referenced
this pull request
Sep 14, 2026
The SD-JWT VC annex cites it for the x5c JOSE header. Addresses Oliver's comment in #57 (comment)
Contributor
|
@redsstriker volunteered to review as well. |
This was
linked to
issues
Sep 19, 2026
jogu
added a commit
that referenced
this pull request
Sep 24, 2026
The mdoc annex introduction says Document is one of the structures defined in ISO/IEC 18013-5, where it is a CBOR map, but the annex CDDL then declared Document = bstr. Name our type MdocData and define it as bstr .cbor Document so the ISO name keeps its ISO meaning and the wire format (a byte string holding the encoded Document) is unchanged. Addresses Oliver's review comment on #57.
Member
|
PR has been updated - Needs review |
|
Then how to avoid collision of credential format definition? |
c2bo
reviewed
Oct 5, 2026
jogu
commented
Oct 5, 2026
awoie
self-requested a review
October 19, 2026 19:17
martijnharing
approved these changes
Oct 19, 2026
Structure agreed at the 2026-08-31 meeting: one normative annex per credential format, with a generic extension point so other documents can define further formats. - New "Credential Formats" clause: the protocol is format agnostic, a "credential format definition" shall specify the ten items from #36, and the main body no longer names any format or annex. - New annexes for ISO mdoc and SD-JWT VC with identical headings in the order of the #21/#22 checklists; existing format text moves there. - format_extensions and CredentialItem.data become CDDL sockets ($formatExtensions, $CredentialData); the undefined ZkDocument / zkFormatExtensions alternatives go away. - ISO/IEC 18013-5, RFC 9901 and draft-ietf-oauth-sd-jwt-vc added to Normative references. - SD-JWT VC format identifier is now dc+sd-jwt; vc+sd-jwt as a mimetype means a w3c vc encoded in sd-jwt; vp uses dc+sd-jwt. New text added by this PR: case-sensitive credential_type matching; mdoc elements may be issuer- or device-signed; mdoc issuer identifiers match the AKI of a certificate in the IssuerAuth x5chain; KB-JWT may be omitted only when support_no_cryptographic_binding is true; for mdocs that flag maps to nonKeyBoundSupported from the 18013-5 second edition DIS text (#56). Left "To be completed": value matching (#9), transaction data (#4), SessionTranscript derivation and KB-JWT nonce/aud (#10), non-X.509 issuer identification for SD-JWT VC. Raised separately: array elements in path (#52), vct inheritance (#53), mdoc alg value names and matching rule (#54) There's now no mention of ZKP responses - that's already recorded in #17 closes #21, #22, #36
The SD-JWT VC annex only said the x509_ref values are compared against the x5c chain, without saying what outcome satisfies the request. Use the same rule as the mdoc annex.
The previous text let the wallet drop the KB-JWT from a key-bound SD-JWT VC whenever support_no_cryptographic_binding was true. That is a downgrade the mdoc annex does not permit (a key-bound mdoc always carries DeviceSigned) and OpenID4VP does not permit either. Tie the permission to the absence of cnf, matching the mdoc rule.
IssuerSignedItems is not a structure in ISO/IEC 18013-5; the standard has IssuerSignedItem entries under IssuerNameSpaces and DeviceSignedItems under DeviceNameSpaces.
The mdoc annex introduction presented its list as the structures the annex refers to, but omitted IssuerAuth, the MSO, KeyAuthorizations, IssuerNameSpaces, DeviceNameSpaces and DeviceSignedItems, all used later in the annex. The SD-JWT VC annex uses the x5c header, which comes from RFC 7515 rather than the SD-JWT documents.
The annexes say format carries the same value as credential_format, but the main-body table did not connect the field to the extension point.
The note that an mDL is always key-bound also relies on the unpublished second edition text, so move the editor's note ahead of it and say it covers both.
Co-authored-by: Oliver Terbu <o.terbu@gmail.com>
The SD-JWT VC annex cites it for the x5c JOSE header. Addresses Oliver's comment in #57 (comment)
The mdoc annex introduction says Document is one of the structures defined in ISO/IEC 18013-5, where it is a CBOR map, but the annex CDDL then declared Document = bstr. Name our type MdocData and define it as bstr .cbor Document so the ISO name keeps its ISO meaning and the wire format (a byte string holding the encoded Document) is unchanged. Addresses Oliver's review comment on #57.
Each annex said in prose that its type extends the $CredentialData or $formatExtensions socket, immediately before the CDDL line that says the same thing. The Credential Formats clause already states the general rule once, so remove the four repetitions.
Co-authored-by: Martijn Haring <62745275+martijnharing@users.noreply.github.com> Co-authored-by: Gareth Oliver <gco@google.com> Co-authored-by: Oliver Terbu <o.terbu@gmail.com> Co-authored-by: Joseph Heenan <joseph@heenan.me.uk>
Martijn and Gareth both asked for the sentence to go: DCHP should not define itself in terms of the ISO/IEC 18013-5 request structure it may replace. DocRequestInfo is no longer referred to, so it leaves the list of borrowed structures too.
The mDL key-binding note the #56 editor's note pointed to has been removed, and item 10 of the format definition requirements lost its full stop when the review suggestion was applied.
(also remove a stray DOS line ending the github web interface added) Co-authored-by: Oliver Terbu <o.terbu@gmail.com>
A suggestion applied in the GitHub web UI converted the whole draft to CRLF, which showed every line as changed and left review comments detached from their lines. I don't know if the web interface pays attentions to .gitattributes but I don't think it can make things worse.
Co-authored-by: Oliver Terbu <o.terbu@gmail.com>
Covers age_over_NN, whose nearest-attestation rule is defined in both ISO/IEC 18013-5 and ISO/IEC TS 23220-2 (used by PhotoID). Co-authored-by: Gareth Oliver <gco@google.com>
Adds RFC 5280 to the Normative references. Co-authored-by: Oliver Terbu <o.terbu@gmail.com>
The response field carries the same value as credential_format in the request, so use the same name and drop the annex sentences that said so. The map key is unchanged, so this does not affect the encoding. Suggested by Martijn Haring. Co-authored-by: Martijn Haring <62745275+martijnharing@users.noreply.github.com>
OpenID4VP and the ISO/IEC 18013-5 second edition DIS (Annex H.2) share the same claims path pointer algorithm, which needs path components other than tstr. Rather than describe a subset of it here, defer to #52. Co-authored-by: Martijn Haring <62745275+martijnharing@users.noreply.github.com>
Co-authored-by: Martijn Haring <62745275+martijnharing@users.noreply.github.com>
PR #61 turned CredentialQuery.credential_type into the credential_types array. Update the format definition requirements and the mdoc and SD-JWT VC credential type sections to describe matching per entry.
jogu
force-pushed
the
jogu/format-annexes
branch
from
October 22, 2026 10:24
4d461ea to
2b6b0f3
Compare
Contributor
Author
|
As #61 will merge first I've updated this PR to be stacked on top of it, and adapted the text in the new format annexes to refer to the credential_types array instead of the old credential_type element. |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Structure agreed at the 2026-08-31 meeting: one normative annex per credential format, with a generic extension point so other documents can define further formats.
New text added by this PR:
Left "To be completed": SD-JWT VC path (#52), value matching (#9), transaction data (#4), SessionTranscript derivation and KB-JWT nonce/aud (#10), non-X.509 issuer identification for SD-JWT VC.
Raised separately: SD-JWT VC path semantics, aligning with the OpenID4VP / 18013-5 claims path pointer (#52), vct inheritance and aka_vcts (#53), mdoc alg value names and matching rule (#54), collision-resistant credential format identifiers (#68), whether alg value lists are mandatory and how the wallet must treat them (#78)
There's now no mention of ZKP responses - that's already recorded in #17
closes #21, #22, #36