Regarding points 1 and 3, the term Holder is defined in [RFC9901] and used in this draft consitant with that. It's not ambiguous. That definition is intentionally broad and meant to simplify text throughout RFC9901 and this draft by allowing to "refer to the actual user, the supporting hardware and software in their possession, or both." If there are areas in this draft that could be improved to make things in that area more clear, let's look at making improvements. However, I believe introducing such a distinction here would be a step in the wrong direction, especially one that changes the meaning from 9901 and relies on capitalizing the first letter of the word.
On Point 2, I would argue that the boundaries of this document are evident without such mentions. Regarding Point 4, this draft defines the JWT vct claim as appropriate for this work. There's no compelling reason or any consensus to replace vct. Especially with this isspol claim that is undefined but seemingly very different. The cwt claim of the same name isn't in scope for this work, despite having the same name. I'm not in a position to comment on the CWT claim definition other than to say it's not something for this draft to address. On Thu, Feb 19, 2026 at 3:06 PM Denis <[email protected]> wrote: > 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 to [email protected] > > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- _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]
