Three comments on Section 2.5, plus one minor note. None of them
blocks publication as far as I am concerned.
Where this comes from: I build a relying-party verifier, listed by
the OpenID Foundation as certified on 11 September 2026 to the
OID4VP-1.0+HAIP-1.0 Verifier sd_jwt_vc direct_post.jwt and iso_mdl
direct_post.jwt profiles. More usefully for this review, it verifies
live PIDs from the European Commission's EUDI Wallet reference
deployment, and all three points below are things I hit doing that.
The credential I refer to throughout was captured from the EC
reference wallet on 5 September 2026:
header: {"alg":"ES256","typ":"dc+sd-jwt","x5c":[<one certificate>]}
iss: "https://backend.issuer.eudiw.dev";
vct: "urn:eudi:pid:1"
The x5c array has exactly one entry. That certificate's subject is
CN=PID DS - 002, O=EUDI Wallet Reference Implementation, C=UT, and it
has no subjectAltName extension. The extensions present are
basicConstraints, authorityKeyIdentifier, authorityInfoAccess,
certificatePolicies, extendedKeyUsage, cRLDistributionPoints,
subjectKeyIdentifier, keyUsage and qcStatements.
So iss is an HTTPS URI that appears nowhere in the certificate.
1. What is iss for when x5c is present?
Section 2.2.2.3 says iss "explicitly indicates the Issuer of the
Verifiable Digital Credential when it is not conveyed by other means
(e.g., the subject of the end-entity certificate of an x5c header)".
I read that as: with x5c present, iss is redundant and carries no
weight.
Section 7.3 pushes the other way. It says it is "critical that those
rules maintain the integrity of the relationship between the iss
value of the SD-JWT, if present, and the public keys of the Issuer."
That reads as: iss still means something, even alongside x5c.
Section 2.5 says nothing about the case where both are present, which
is the shape of every EU reference credential I have seen.
This is not theoretical. Credo (credo-ts) v0.7.0 requires iss to
match a SAN-URI entry in the end-entity certificate, or its domain to
match a SAN-DNS entry, and rejects the credential otherwise. Against
the EC reference issuer that rejects everything, because there is no
SAN to match. We carry a patch to relax it. Someone reading the same
text has clearly reached the opposite conclusion from mine.
One sentence in Section 2.5 would settle it. Either:
"When the x5c parameter is present, the iss claim is not used for
key discovery and MUST NOT be required to correspond to any name
in the end-entity certificate."
or a statement of whatever matching rule is intended. I do not mind
which. I would like the document to pick one.
2. Nothing says which mechanism to use when both apply
Section 7.3 says: "A Verifier MUST ensure that for any given iss
value, an attacker cannot influence the type of verification process
used."
I agree with the requirement. My problem is that Section 2.5 gives me
no way to satisfy it for the two mechanisms this document itself
defines. The credential above triggers both: iss is an HTTPS URI, and
x5c is present. Section 2.5 lists the two without precedence, and the
rejection rule at the end of 2.5 is satisfied by "a permitted key
discovery and validation mechanism" - any one of them.
They are not equivalent. Under x5c I end up at a key whose
certificate chains to an anchor I already hold, which in the EU case
was put on a trusted list by a third party. Under JWT VC Issuer
Metadata I end up at whatever key is served at the iss URL, and iss
is a value the credential asserts about itself. Anyone can mint a
credential, point iss at a domain they control, publish a key there
and pass. I dropped the metadata path from my verifier for that
reason.
Section 2.4's "permitted for the Issuer according to policy" is the
hook for making that choice, and I used it. But a verifier built from
this document with no policy layer will accept both, which is the
situation 7.3 says must not arise.
Suggestion: say in Section 2.5 that when x5c is present the recipient
MUST use the x5c mechanism and MUST NOT fall back to JWT VC Issuer
Metadata for the same credential. If the working group would rather
leave it to policy, then say that the choice MUST be fixed by policy
per Issuer and MUST NOT be driven by what the credential presents.
3. "validates the X.509 certificate chain accordingly" - against what?
Section 2.5 says the recipient "validates the X.509 certificate chain
accordingly". The document does not say what that means, and there is
no reference to RFC 5280 anywhere in it. "Trust anchoring systems"
appears twice in 2.5, but nothing requires the recipient to hold a
trust anchor.
Read literally, checking that the certificates in x5c are internally
consistent satisfies "validates the chain". That establishes nothing,
because the credential supplied those certificates.
Again not theoretical: the EU credential ships one certificate. There
is no chain in it. Everything above the end-entity certificate has to
come from my own configuration, and if I hold no applicable anchor
the right answer is to refuse.
Suggestion, after "validates the X.509 certificate chain
accordingly":
"Chain validation is performed as described in [RFC5280] and MUST
terminate at a trust anchor that the recipient obtained out of
band and that is permitted for the Issuer according to policy.
Certificates conveyed in the x5c parameter MUST NOT be treated as
trust anchors. A recipient with no applicable trust anchor MUST
reject the SD-JWT VC."
Minor: the absence of status is silent
Section 2.4 says "If status is present in the verified payload of the
SD-JWT, the status SHOULD be checked. Verifier policy decides whether
to reject or accept a presentation of a SD-JWT VC based on the status
of the Verifiable Digital Credential." That covers what to do with a
status value. It does not cover a credential that carries no status
claim at all, where a Verifier cannot distinguish "not revoked" from
"not revocable" and has nothing to base a policy on. If that is meant
to be established out of band, one sentence saying so would help. I
have seen implementations report a revocation check that never ran.
Nas Til
LimogiAI Solutions Inc. / VerySafe
https://verysafe.id
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
