Summary

  • On 1 September, the IESG opened an IETF-wide Last Call on revision -19 of SD-JWT-based Verifiable Digital Credentials. The OAuth Working Group seeks publication as a Proposed Standard; comments close on 15 September and no approval has been announced.
  • The draft lets a credential identify one required type with vct, assert additional types through aka_vcts, and inherit Type Metadata through extends.
  • Those mechanisms support matching and reuse. The draft expressly says they do not authorize an issuer to issue a recognized type, and that Type Metadata is trustworthy only when its publisher is authoritative for that type.
  • A verifier therefore needs two mandate edges outside the token: one for the issuer and one for the metadata publisher. A signature, alias, inheritance chain or integrity hash cannot manufacture either edge.
  • An ecosystem-specific authority receipt can expose those decisions without asking the IETF to operate a universal issuer registry.

The type match happens before the trust decision

The IETF is reviewing a format that may sit underneath identity documents, licences, qualifications and other digital claims. On 1 September, the Internet Engineering Steering Group opened Last Call on draft-ietf-oauth-sd-jwt-vc-19. The OAuth Working Group has asked for the document to become a Proposed Standard. The review ends on 15 September. At the evidence cutoff, the Datatracker showed no telechat date, an IANA review still needed and no final IESG decision.

The draft builds on RFC 9901. In the base SD-JWT mechanism, an issuer signs a JSON payload containing ordinary claims and digests for claims that may be disclosed later. A holder presents a chosen subset. A verifier checks the issuer signature and the disclosure digests and, when the applicable policy requires it, holder key binding.

SD-JWT VC gives that mechanism a credential shape. Every credential carries a case-sensitive, collision-resistant vct identifier. The identifier tells software what type of credential it is handling and which claims or disclosure rules apply. The draft deliberately defines no actual vct values. Those are left to ecosystems, along with their meaning and issuance and validation policies beyond the common format.

That division is sensible. A transportable technical format cannot decide who may issue a driving licence, professional qualification, employee badge or community membership. The danger begins when software treats a type match as if the decision had already been made.

Two routes can connect types

Revision -19 offers two related but independent mechanisms. Type Metadata may use extends to say that one type derives from another. The consumer processes the parent first. Claim rules carry forward, and a child cannot relax an inherited mandatory field or reverse a fixed selective-disclosure constraint. This gives implementers a controlled form of reuse instead of copying every rule into every local subtype.

The optional aka_vcts claim works at credential level. An issuer can assert that the credential also belongs to additional types. That is useful when an issuance or presentation protocol asked for a general type but receives a more specific one. It also works when Type Metadata is unavailable. The array's order conveys nothing, and the listed types do not have to be connected by extends.

The distinction matters. extends is a relation published in Type Metadata. aka_vcts is an assertion made by the credential issuer. Either may help software answer “does this credential match the requested type?” Neither, on its own, answers “may this actor issue that type?”

The draft says this directly. An attacker could mint a type that mimics or extends a legitimate one. Verifiers and holders must not accept it solely because the hierarchy looks familiar. They must verify issuer identity, trust status and any relevant accreditation or registry independently. The same warning applies to aka_vcts: it is only as trustworthy as the issuer making the assertion.

A second authority edge sits behind the metadata

There is another actor in the design. A Type Metadata publisher can be a standards body, community, ecosystem authority or another party defining a type. It need not be the credential issuer. Its document can describe claims, display properties, inheritance and integrity information.

Fetching that document over HTTPS does not make the publisher authoritative. Nor does verifying a hash. Transport and integrity can show where bytes came from and whether they changed. They cannot show that this publisher received the right to define the type. Section 7.8 therefore says consumers must not assume the metadata is accurate or meaningful unless the publisher is recognized as authoritative for the type. It urges ecosystems to define governance or accreditation mechanisms for publishers and the conditions under which their metadata may be relied upon.

That creates two separate authorization questions. Who allowed the issuer to make credentials of this type? Who allowed the publisher to define or describe the type metadata? The same institution may answer both questions, but the format does not guarantee that. Combining them in a single “verified” badge would conceal the very separation the draft preserves.

Signatures prove control, not mandate

This is not an argument against cryptographic verification. The draft requires the verifier to establish that the signing key belongs to the asserted issuer through a discovery and validation method allowed by the relevant policy. If it cannot do so, it rejects the credential. That is a strong and necessary proposition: the bytes were signed by the key associated with this issuer under this validation method.

But an issuer can control its own key without being authorized to issue a national identity credential. A rogue metadata publisher can serve an internally consistent inheritance chain. A perfectly calculated integrity value can preserve unauthorized content without altering it. Cryptography protects the statement and its provenance; it does not create the institution behind the statement.

Heng Lu describes the broader failure as mandate laundering: a technical or institutional wrapper is allowed to impersonate the authority it merely references. In this setting the laundering path is short. A familiar vct becomes a familiar visual card; the card gets a successful signature indicator; the indicator is then read as permission to issue. Each step may be locally correct while the conclusion is false.

The draft's achievement is to stop that inference in normative language. The implementation task is to keep the stop visible in operational records and user interfaces.

Give the verifier an authority receipt

The missing artifact does not need to be a global trust list. Each credential ecosystem can publish a compact authority receipt for the issuer/type combination it accepts.

Receipt field Question it preserves
Exact vct, accepted aka_vcts and extends chain What type relationship did the verifier actually process?
Issuer identifier and key-validation method Which actor and key signed the credential?
Issuer authority source Which registry, accreditation, law, contract or trust-list record permits issuance?
Type Metadata publisher and integrity reference Who supplied the semantic and display rules, and which version was used?
Publisher authority source Why may that publisher define or describe this type?
Scope and validity interval In which ecosystem, jurisdiction and period does the mandate apply?
Verifier-policy version and decision time Under which rule set was acceptance reached?
Explicit non-conclusion Which technical checks do not independently establish institutional authority?

The receipt can point to public or privacy-bounded sources. It should be cacheable and versioned. It should not contain holder-specific data. It should also distinguish “not checked,” “not found,” “expired,” “outside scope” and “affirmatively unauthorized”; collapsing those states would turn missing evidence into an accusation.

The receipt is an editorial proposal, not text in revision -19. Its job is modest: preserve the external policy decision that the format intentionally does not make.

Keep the cure outside the wire format

The strongest objection is that every sector and jurisdiction has a different authority model. An IETF credential format should not embed licensing law, government procurement, university accreditation and private membership rules into one schema. A central registry would create a new control point, make local schemes dependent on a global operator and age as mandates change.

That objection is correct. The authority receipt belongs in an ecosystem profile, verifier policy, wallet trust configuration or scheme registry. The IETF should maintain the technical boundary and the hooks needed to apply external policy. It should not become the issuer of issuers.

Nor should the receipt weaken aka_vcts. Type aliasing remains useful where Type Metadata is absent, and inheritance remains useful for preserving common claim rules. The point is to stop either mechanism at the edge of the proposition it can prove.

The privacy design needs equal care. Type identifiers are not selectively disclosable and can reveal the context of a credential. The draft also warns that a holder-specific issuer identifier can create a phone-home trail when a verifier fetches issuer metadata. An authority check that contacts the issuer on every presentation could convert trust verification into observation. Receipts should therefore attach to stable issuer/type combinations, support caching or pinning and avoid per-holder lookup keys.

Sources

  1. IETF — Last Call on SD-JWT-based Verifiable Digital Credentials -19
  2. IETF Datatracker — SD-JWT VC document record
  3. IETF Internet-Draft — SD-JWT VC revision -19
  4. RFC 9901 — Selective Disclosure for JSON Web Tokens
  5. IESG — Last Call Guidance to the Community
  6. IETF — OAuth Working Group charter
  7. Heng Lu — Mandate Laundering