Add a new claim called "credential_issuance_policy" #565
Description
On Dec 7, 2024, I raised the following issue ":
Add a new claim called "dcpol" for "Digital Credential Policy" #290
wbl responded:
What's a Digital Credential Policy? This would need a lot more text to explain the semantics.
Below is a "lot more text to explain the semantics". In between, I changed the name of the claim into: "credential_issuance_policy".
An analogy between X.509 Certificates and Verifiable Credentials can be made.
X.509 Certificates are defined in RFC 5280.
Section 2 from RFC 5280 states:
A certificate user should review the certificate policy generated by the certification authority (CA) before relying on the authentication or non-repudiation services associated with the public key in a particular certificate.
Applying this analogy, the current draft should state something like:
A verifier user should review the credential_issuance_policy claim placed by the issuer into a Verifiable Credential before relying on authentication or selective disclosure services associated with the public key in a particular Verifiable Credential.
Unfortunately, at the moment, no claim has been defined for a "Credential issuance policy (CIP)".
Section 4.2.1.4 from RFC 5280 states:
4.2.1.4. Certificate Policies
The certificate policies extension contains a sequence of one or more policy information terms, each of which consists of an object identifier (OID) and optional qualifiers. Optional qualifiers, which MAY be present, are not expected to change the definition of the policy. A certificate policy OID MUST NOT appear more than once in a certificate policies extension.
In an end entity certificate, these policy information terms indicate the policy under which the certificate has been issued and the purposes for which the certificate may be used.
Applying this analogy, the current draft would state something like:
The credential_issuance_policy claim contains a sequence of one or more credential issuance policy identifiers, each of which consists of a URI and optional policy qualifiers. Optional policy qualifiers, which MAY be present, are not expected to change the definition of the policy. A credential issuance policy identifier URI MUST NOT appear more than once in a credential_issuance_policy claim.
The credential_issuance_policy claim indicates the policies under which the verifiable credential has been issued and the purposes for which it may be used.
Verifiers with specific policy requirements are expected to have a list of those policies that they will accept and to compare the policy URI in the verifiable credential to that list.
This specification defines one policy qualifier type: the Issuance Practice Statement (issuance_practice_statement).
The issuance_practice_statement qualifier contains a pointer to an Issuance Practice Statement (IPS) either published by the issuer or defined by another organization. The pointer is in the form of a URI. Processing requirements for this qualifier by Relying Parties are a local matter.
Another analogy can also be done with ETSI EN 319 412-5 V2.4.1 (2023-09).
Section 4.2.2 is stating:
4.2.2 QCStatement claiming that the private key related to the certified public key resides in a QSCD
This Qcstatement declares that the private key related to the certified public key resides in a Qualified Signature/Seal Creation Device (QSCD) according to the Regulation (EU) No 910/2014 [i.8] or a secure signature creation device as defined in the Directive 1999/93/EC [i.3].
Syntax:
esi4-qcStatement-4 QC-STATEMENT ::= { IDENTIFIED BY id-etsi-qcs-QcSSCD }
id-etsi-qcs-QcSSCD OBJECT IDENTIFIER ::= { id-etsi-qcs 4 }
Applying this analogy, the current draft would state something like:
The following issuance_practice_statement URI declares that the keys pairs generated by a holder and used for requesting the issuance of verifiable credential and then after for presenting them to relying parties reside in a device that restricts the use of the private keys to a specific application placed under the control of the owner of this device. The application that can present verifiable credentials must also be the application that requested and obtained them.
Syntax: ...
Using the ARF vocabulary (Discussion topic C - Wallet Unit Attestation (WUA) and Key Attestation Version 0.4, updated 14 March 2025), the URI contained in an issuance_practice_statement corresponds to the "properties of the WSCA".
Relying Parties can rely on issuance_practice_statements contained in a verifiable credential and thus do not need to use any protocol with WSCA to know the "properties of the WSCA".
In this way, a protocol between the WSCA and Relying Parties using Wallet Unit Attestations is replaced by the issuance_practice_statement placed into the verifiable credential. One-time use Wallet Unit Attestations (WUA) are still necessary between WSCAs and issuers, but are not necessary between WSCAs and Relying Parties.
Note: This topic has been raised at the end of the presentation from Daniel and Olivier on July 2, 2025 (SD-JWT and SD-JWT VC deep dive)
at the "Global Digital Collaboration Conference 2025" in Geneva.