I have four points.
*Point 1*
Section 1.1. Issuer-Holder-Verifier Model
There are the following sentences:
"In the so-called Issuer-Holder-Verifier Model, Issuers issue
Verifiable Digital Credentials to a Holder, who can then present the
credentials to Verifiers.
Verifiable Digital Credentials are cryptographically secured
statements about a Subject, typically the Holder".
This sentence introduces a confusion about a subject and an Holder.
A Holder with an uppercase letter "H" is an application, i.e., a piece
of software supported by a device.
It is also possible to use the term "holder" with a lowercase "h" to
designate the entity to which the statement relates.
it is thus propose to replace the quoted sentences by:
In the so-called Issuer-Holder-Verifier Model, Issuers issue digital
credentials to a Holder (with the uppercase letter "H"),
which is an application that can then transform digital credentials
into a digital credential proof that can then be presented to
Verifiers.
Digital credentials are cryptographically secured statements about
an entity, typically an individual. The entity that holds the
digital credentials,
is called a holder (with the lowercase letter "h"). When the entity
to which the statement relates is an individual, the digital
credential proof is released
to a verifier after the consent of the holder.
Figures 1 shows:
Issues SD-JWT VC
|
v
+------------+
| |
| Holder |
| |
+------------+
|
Presents SD-JWT VC
However, the data that is above the Holder box is not the same as the
data that is below the Holder box.
Using wordings like "Issues SD-JWT VC" and "Presents SD-JWT VC" is
confusing. These labels should be changed.
A proposal is below:
Issues SD-JWT VC
including all Disclosures
|
v
+------------+
| |
| Holder | <--- holder (presents the user consent)
| |
+------------+
|
Presents SD-JWT VC or SD-JWT VC + KB
including selected Disclosures
*Point 2*
The text continues with:
*Verifiers can check the authenticity of the data in Verifiable
Digital Credentials. Verifiers can also optionally enforce Key
Binding, which requires the Holder to prove they are the intended
Holder of the Verifiable Digital Credential. This proof is typically
done by demonstrating possession of a cryptographic key referenced in
the credential. This process is further described in [RFC9901].*
This text is making two assumptions that should be mentioned, so that
readers can understand the boundaries of this document.
1) while there exist mechanisms able to construct a single digital
credential proof from several digital credentials,
this document only considers the construction of a digital
credential proof using a single digital credential
2) this document is implicitly only using conventional cryptography
(while ZKP cryptography would also be usable).
Text replacement proposal:
In this document, a digital credential proof is built using a single
digital credential. Verifiers can check the origin and the integrity
of a digital credentials proof. In this document, only conventional
cryptography is used. Verifiers can also optionally verify Key Binding,
which requires the Holder to prove it can demonstrate the knowledge
of a private key corresponding to a public key that has been placed
by the Issuer into the digital credential. In this way, the digital
credential is bound to a private key. This process is further
described in [RFC9901].
*Point 3*
*1.4. Terms and Definitions
This specification uses the terms "Holder", "Issuer", "Verifier",
"Disclosure", "Selectively Disclosable JWT (SD-JWT)", "Key Binding",
"Key Binding JWT (KB-JWT)", "Selectively Disclosable JWT with Key
Binding (SD-JWT+KB)" defined by [RFC9901].*
The definition of the term Holder as defined in [RFC9901] is ambiguous.
It is:
*Holder:
An entity that received SD-JWTs from the Issuer and has control
over them. In the context of this document, the term may refer to
the actual user, the supporting hardware and software in their
possession, or both.*
This definition does not make a difference between an actual "user" and
a "supporting hardware and software".
A user is usually an individual (i.e., a human being) who should not be
assimilated to or confused with a "supporting hardware and software".
Two different terms should be used: one to designate the user and
another one designating the supporting software and hardware.
It is proposed to use the term "Holder" (with an uppercase letter "H")
and the term "holder" with a lowercase letter "h", which are defined below
Change proposal:
1.4. Terms and Definitions
This specification uses the terms "Issuer", "Verifier",
"Disclosure", "Selectively Disclosable JWT (SD-JWT)", "Key Binding",
"Key Binding JWT (KB-JWT)", "Selectively Disclosable JWT with Key
Binding (SD-JWT+KB)" defined by [RFC9901].
Holder:
An application supported by some hardware that receives SD-JWT
VCs including all Disclosures
from the Issuer, has control over them and that transforms them
into SD-JWT VC or SD-JWT VC + KB
including selected Disclosure that are then presented to
Verifiers. The term Holder is written with an uppercase letter "H".
holder:
An entity that holds digital credentials that contains statements
about it. Most often, a holder is an individual. When it is the
case and when selective disclosure is used, before the Holder
produces a SD-JWT VC or SD-JWT VC + KB including selected
Disclosures that will be presented to the Verifier, the holder is
requested
to provide its consent to the Holder. The term holder is written
with a lowercase letter "h".
*Point 4*
There are two different semantics for the same claim name: vct Claim,
i.e. in this document and in draft-ietf-spice-sd-cwt-06.
1) Section 3.2.2.1 (Verifiable Digital Credential Type - vct Claim), of
draft-ietf-oauth-sd-jwt-vc-14 states:
*This specification defines the new JWT claim vct (for verifiable
credential type). Its value MUST be a case-sensitive string serving
as an identifier for the type of the SD-JWT VC. The vct value MUST
be a Collision-Resistant Name as defined in Section 2 of [RFC7515].
A type is associated with rules defining which claims are permitted
or required to appear in the Unsecured Payload of the SD-JWT VC and
whether selective disclosure is permitted, necessary, or prohibited
for those claims.*
2) Section 13 (Credential Types) of draft-ietf-spice-sd-cwt-06 states
*This specification defines the CWT claim vct (for Verifiable
Credential Type). The vct value is an identifier for the type of the
SD-CWT Claims Set. Like the typ header parameter [RFC9596], its value
can be either a string or an integer. For size reasons, it is
RECOMMENDED that the numeric representation be used.
If its value is a string, it is a case-sensitive StringOrURI, as
defined in [RFC7519]. In this case, the vct string MUST either be
registered in the IANA "Verifiable Credential Type Identifiers"
registry established in Section 17.8, or be a Collision-Resistant
Name, as defined in Section 2 of [RFC7515].
If its value is an integer, it is either a value in the range 0-64999
registered in the IANA "Verifiable Credential Type Identifiers"
registry established in Section 17.8 or an Experimental Use value in
the range 65000-65535, which is not to be used in operational
deployments.*
In the claim registry, there is the following information:
vct (TEMPORARY - registered 2025-12-02, expires 2026-12-02)
[draft-ietf-spice-sd-cwt-06, Section 13]
This needs to be fixed.
It is not believed that any of these two different semantics and
encoding is adequate.
It is important to know under which issuing policy (isspol) a given
credential has been issued.
An issuing policy is much wider concept than an "identifier for the type
of the SD-JWT VC".
It defines the conditions that the Holder must satisfy so that this
digital credential format can be issued
and the conditions that the holder must satisfy so that this digital
credential format can be issued.
It is important to be able to dereference the value contained in this
field and to make it unique.
It is thus proposed to mandate that this field shall only contain either
a URN or an OID.
The isspol claim shall be REQUIRED.
It is thus proposed to replace the vct claim by an isspol claim and to
register it at IANA.
Section A.1 (JSON Web Token Claims Registration) should be modified
accordingly.
Denis
Internet-Draft draft-ietf-oauth-sd-jwt-vc-14.txt is now available. It is a
work item of the Web Authorization Protocol (OAUTH) WG of the IETF.
Title: SD-JWT-based Verifiable Digital Credentials (SD-JWT VC)
Authors: Oliver Terbu
Daniel Fett
Brian Campbell
Name: draft-ietf-oauth-sd-jwt-vc-14.txt
Pages: 65
Dates: 2026-02-05
Abstract:
This specification describes data formats as well as validation and
processing rules to express Verifiable Digital Credentials with JSON
payloads with and without selective disclosure based on the SD-JWT
[RFC9901] format.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-14.html
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-sd-jwt-vc-14
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
OAuth mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
