Dear authors, chairs and IESG, I write in support of publication of draft-ietf-oauth-sd-jwt-vc-19 as a Proposed Standard, with two comments from an implementer whose Subjects are not people.
We are implementing SD-JWT VC in FaunaMark, a conservation-verification scheme in which accredited certification bodies issue credentials about individually identified wild animals to the reserves and wildlife authorities that hold them, so that a claimed population count can be verified one animal at a time [1]. The Subject of every credential is an individual animal; the Holder is its custodian; the Verifier is a buyer of conservation outcomes or a regulator. That shape, Subject distinct from Holder and not a natural person, is common outside our field too (a device, an artefact, a consignment, a work of art), and the draft handles it well at the encoding level. Two places would benefit from a sentence each. 1. Section 2.2.2.3 (sub) and Section 8.2 (Privacy: Verifiable Digital Credential Type Identifier) Section 2.2.2.3 already says of sub that "There is no requirement for a binding to exist between sub and cnf claims", which is exactly what a custodian-held credential needs: cnf binds the Holder's key, sub identifies the Subject. The privacy considerations, however, speak of the Holder only. Section 8.2 advises Issuers to choose vct values "following data minimization principles" so that third parties cannot infer "additional personal information about the Holder", and RFC 9901 Section 10 is likewise about the Holder's unlinkability. Where the Subject is a protected entity, the same leakage harms the Subject. In our case a vct value or a sub value that reveals the species, the reserve or the individual gives a third party what it needs to locate an endangered animal, and neither vct nor aka_vcts is selectively disclosable, so the Holder cannot suppress it at presentation. The draft already contains the principle; it only names one beneficiary. Proposed text, Section 2.2.2.3, after the existing sub bullet: "The Subject identified by sub is not necessarily the Holder and need not be a natural person. Where the Subject is an entity distinct from the Holder, sub SHOULD be an identifier chosen with the Subject's protection in mind (see Section 8.2)." Proposed text, Section 8.2, as a final paragraph: "The same data minimization considerations apply where the Subject of the credential is an entity distinct from the Holder, such as an object, an animal or a device: the vct and aka_vcts values, which cannot be selectively disclosed, and the sub value, which may be disclosed, can reveal information about the Subject that the Holder has no means to withhold." 2. Section 7.7 (Credential Type Extension and Issuer Authorization) and Section 7.8 (Trust in Type Metadata) Section 7.7 requires implementations to "verify the issuer's authorization independently of the credential type", by "checking the issuer's identity, trust status, and any relevant accreditation or registry", and Section 7.8 asks ecosystems to "define governance or accreditation mechanisms that specify which Publishers are authorized to provide Type Metadata". We agree with both. One pattern the two sections do not name, and which is the normal shape of a certification ecosystem, is that the Publisher of the Type Metadata and the Issuer are different parties by design: the scheme owner defines the type and publishes its Type Metadata, and accredited certification bodies issue credentials of that type. This is the separation of scheme owner and certification body in conformity assessment (ISO/IEC 17065 and 17029) and, in the European Union, the separation of operator, certification body and certification scheme in Regulation (EU) 2024/3012. In such an ecosystem the check that Section 7.7 requires is a lookup of the iss value in the scheme owner's register of accredited issuers, and the Type Metadata, integrity-protected through vct#integrity, is the natural place for the scheme owner to bind the rules of the type. Proposed text, Section 7.7, after the three bullets: "In ecosystems organised as certification schemes, the party that defines the type and publishes its Type Metadata (the scheme owner) is distinct from the parties authorized to issue credentials of that type (accredited certification bodies). Verifiers in such ecosystems verify issuer authorization against the scheme owner's register of accredited Issuers, and MUST NOT infer it from the Issuer's use of the type." Proposed text, Section 7.8, one sentence after "Ecosystems SHOULD define governance or accreditation mechanisms...": "Where the Publisher is the owner of a certification scheme, its Type Metadata is also the natural place to reference the scheme's rules and its register of authorized Issuers." Neither comment asks for a new claim, property or processing rule, and neither should delay publication. Thank you for the work on this document; the type metadata and integrity mechanisms of the recent revisions are what made it adoptable for us. Kind regards, Albertus B. Geldenhuys Manager, Terra Perpetua Conservation Division The Art Company AG, Baarerstrasse 82, 6300 Zug, Switzerland FaunaMark® (Swiss trade mark No. 852779): individual-level wildlife identity verification for conservation finance [1] Geldenhuys, A. B. (2026). Money or Evidence? Two Conservation-Finance "Innovations" That Should Not Be Confused. Zenodo. https://doi.org/10.5281/zenodo.22016200 _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
