From f6db6e79eee5a2f32761ac954bde1b7e1fb26689 Mon Sep 17 00:00:00 2001 From: Jan Vereecken Date: Thu, 5 Mar 2026 17:47:58 +0100 Subject: [PATCH 1/3] Explain how credential issuer indicates cryptographic key binding is not required --- 1.0/openid-4-verifiable-credential-issuance-1_0.md | 2 ++ 1.1/openid-4-verifiable-credential-issuance-1_1.md | 2 ++ 2 files changed, 4 insertions(+) diff --git a/1.0/openid-4-verifiable-credential-issuance-1_0.md b/1.0/openid-4-verifiable-credential-issuance-1_0.md index fb375b9f..94f46b00 100644 --- a/1.0/openid-4-verifiable-credential-issuance-1_0.md +++ b/1.0/openid-4-verifiable-credential-issuance-1_0.md @@ -1554,6 +1554,8 @@ One such use case is low assurance Credentials, such as coupons or tickets. Another use case is when the Credential Issuer uses cryptographic schemes that can provide binding to the End-User possessing that Credential without explicit cryptographic material being supplied by the application used by that End-User. For example, in the case of the BBS Signature Scheme, the issued Credential itself is a secret and only a derivation from the Credential is presented to the Verifier. Effectively, the Credential is bound to the Credential Issuer's signature on the Credential, which becomes a shared secret transferred from the Credential Issuer to the End-User. +If Cryptographic Key Binding is not required, the Credential Issuer omits the `cryptographic_binding_methods_supported` parameter in the `credential_configurations_supported` object in the Credential Issuer Metadata as defined in (#credential-issuer-parameters). + ## Multiple Accesses to the Credential Endpoint The Credential Endpoint can be accessed multiple times by a Wallet using the same Access Token, even for the same Credential. The Credential Issuer determines if the subsequent successful requests will return the same or an updated Credential, such as having a new expiration time or using the most current End-User claims. diff --git a/1.1/openid-4-verifiable-credential-issuance-1_1.md b/1.1/openid-4-verifiable-credential-issuance-1_1.md index d6c165aa..5edd4636 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -1979,6 +1979,8 @@ One such use case is low assurance Credentials, such as coupons or tickets. Another use case is when the Credential Issuer uses cryptographic schemes that can provide binding to the End-User possessing that Credential without explicit cryptographic material being supplied by the application used by that End-User. For example, in the case of the BBS Signature Scheme, the issued Credential itself is a secret and only a derivation from the Credential is presented to the Verifier. Effectively, the Credential is bound to the Credential Issuer's signature on the Credential, which becomes a shared secret transferred from the Credential Issuer to the End-User. +If Cryptographic Key Binding is not required, the Credential Issuer omits the `cryptographic_binding_methods_supported` parameter in the `credential_configurations_supported` object in the Credential Issuer Metadata as defined in (#credential-issuer-parameters). + ## Multiple Accesses to the Credential Endpoint The Credential Endpoint can be accessed multiple times by a Wallet using the same Access Token, even for the same Credential. The Credential Issuer determines if the subsequent successful requests will return the same or an updated Credential, such as having a new expiration time or using the most current End-User claims. From 9609ed253562fc0ba6615999654ad10d668b6b50 Mon Sep 17 00:00:00 2001 From: Kristina <52878547+Sakurann@users.noreply.github.com> Date: Wed, 22 Apr 2026 10:18:44 +0200 Subject: [PATCH 2/3] based on the discussion in the wg call Co-authored-by: Paul Bastian Co-authored-by: Jan Vereecken --- 1.0/openid-4-verifiable-credential-issuance-1_0.md | 2 +- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/1.0/openid-4-verifiable-credential-issuance-1_0.md b/1.0/openid-4-verifiable-credential-issuance-1_0.md index 94f46b00..52486778 100644 --- a/1.0/openid-4-verifiable-credential-issuance-1_0.md +++ b/1.0/openid-4-verifiable-credential-issuance-1_0.md @@ -1554,7 +1554,7 @@ One such use case is low assurance Credentials, such as coupons or tickets. Another use case is when the Credential Issuer uses cryptographic schemes that can provide binding to the End-User possessing that Credential without explicit cryptographic material being supplied by the application used by that End-User. For example, in the case of the BBS Signature Scheme, the issued Credential itself is a secret and only a derivation from the Credential is presented to the Verifier. Effectively, the Credential is bound to the Credential Issuer's signature on the Credential, which becomes a shared secret transferred from the Credential Issuer to the End-User. -If Cryptographic Key Binding is not required, the Credential Issuer omits the `cryptographic_binding_methods_supported` parameter in the `credential_configurations_supported` object in the Credential Issuer Metadata as defined in (#credential-issuer-parameters). +If Cryptographic Key Binding is not required, the Credential Issuer omits the `cryptographic_binding_methods_supported` parameter in the `credential_configurations_supported` object in the Credential Issuer Metadata as defined in (#credential-issuer-parameters). As a consequence, the `proof_types_supported` parameter is also absent, indicating to the Wallet to omit the `proofs` parameter in the Credential Request. ## Multiple Accesses to the Credential Endpoint diff --git a/1.1/openid-4-verifiable-credential-issuance-1_1.md b/1.1/openid-4-verifiable-credential-issuance-1_1.md index 5edd4636..d7eca19b 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -1979,7 +1979,7 @@ One such use case is low assurance Credentials, such as coupons or tickets. Another use case is when the Credential Issuer uses cryptographic schemes that can provide binding to the End-User possessing that Credential without explicit cryptographic material being supplied by the application used by that End-User. For example, in the case of the BBS Signature Scheme, the issued Credential itself is a secret and only a derivation from the Credential is presented to the Verifier. Effectively, the Credential is bound to the Credential Issuer's signature on the Credential, which becomes a shared secret transferred from the Credential Issuer to the End-User. -If Cryptographic Key Binding is not required, the Credential Issuer omits the `cryptographic_binding_methods_supported` parameter in the `credential_configurations_supported` object in the Credential Issuer Metadata as defined in (#credential-issuer-parameters). +If Cryptographic Key Binding is not required, the Credential Issuer omits the `cryptographic_binding_methods_supported` parameter in the `credential_configurations_supported` object in the Credential Issuer Metadata as defined in (#credential-issuer-parameters). This is a signal for the Wallet to omit the `proofs` parameter in the Credential Request. ## Multiple Accesses to the Credential Endpoint From 50b0fa14e52f44b43addb97f4b1b2188d57c11ab Mon Sep 17 00:00:00 2001 From: Kristina <52878547+Sakurann@users.noreply.github.com> Date: Thu, 23 Apr 2026 17:42:40 +0200 Subject: [PATCH 3/3] aligning text in 1.0 and 1.1 Co-authored-by: Stefan Charsley --- 1.1/openid-4-verifiable-credential-issuance-1_1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1.1/openid-4-verifiable-credential-issuance-1_1.md b/1.1/openid-4-verifiable-credential-issuance-1_1.md index d7eca19b..23ed96b7 100644 --- a/1.1/openid-4-verifiable-credential-issuance-1_1.md +++ b/1.1/openid-4-verifiable-credential-issuance-1_1.md @@ -1979,7 +1979,7 @@ One such use case is low assurance Credentials, such as coupons or tickets. Another use case is when the Credential Issuer uses cryptographic schemes that can provide binding to the End-User possessing that Credential without explicit cryptographic material being supplied by the application used by that End-User. For example, in the case of the BBS Signature Scheme, the issued Credential itself is a secret and only a derivation from the Credential is presented to the Verifier. Effectively, the Credential is bound to the Credential Issuer's signature on the Credential, which becomes a shared secret transferred from the Credential Issuer to the End-User. -If Cryptographic Key Binding is not required, the Credential Issuer omits the `cryptographic_binding_methods_supported` parameter in the `credential_configurations_supported` object in the Credential Issuer Metadata as defined in (#credential-issuer-parameters). This is a signal for the Wallet to omit the `proofs` parameter in the Credential Request. +If Cryptographic Key Binding is not required, the Credential Issuer omits the `cryptographic_binding_methods_supported` parameter in the `credential_configurations_supported` object in the Credential Issuer Metadata as defined in (#credential-issuer-parameters). As a consequence, the `proof_types_supported` parameter is also absent, indicating to the Wallet to omit the `proofs` parameter in the Credential Request. ## Multiple Accesses to the Credential Endpoint