Hi Nas, It doesn't look like your message made it into the mail archives (maybe held up in moderation or something) but this response should and hopefully serve as acknowledgement. I did also see the issues created in the repo <https://github.com/oauth-wg/oauth-sd-jwt-vc/issues?q=is%3Aissue+author%3ANas2020>, thank you, and anticipate we will likely use that to track addressing them or any further discussions.
On Mon, Sep 14, 2026 at 6:27 PM Nas Til <[email protected]> wrote: > 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 > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
