Skip to content

Rephrase conditions to provide nonce in proof types based on presence of Nonce endpoint #678

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
awoie wants to merge 11 commits into
base: main
Choose a base branch
from
Open

Rephrase conditions to provide nonce in proof types based on presence of Nonce endpoint #678

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
be34758
fix: rephrased conditions to provide nonce in proof types based on pr…
awoie Nov 11, 2025
e8d2ae4
ed: updated history
awoie Nov 11, 2025
7fb46cb
Applied Kristina's suggestion
awoie Nov 11, 2025
ee4b878
fix: improved nonce language
awoie Dec 7, 2025
15bc74f
fix: rephrased conditions for including nonce applied to 1.0
awoie Dec 7, 2025
1a0081f
Merge branch 'main' into awoie/fix-677
awoie Dec 7, 2025
949a6bc
Applied Gareth's suggestion
awoie Jan 27, 2026
7c87435
Applied Gareth's suggestion
awoie Jan 27, 2026
14e5f47
Making text consistent with other proof types
awoie Jan 27, 2026
1cd24ab
Making text consistent with other proof types
awoie Jan 27, 2026
e68347b
Merge branch 'main' into awoie/fix-677
Sakurann Apr 23, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions 1.0/openid-4-verifiable-credential-issuance-1_0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1047,7 +1047,7 @@ If the Wallet is requesting the issuance of a Credential that is not supported b
* `unknown_credential_configuration`: Requested Credential Configuration is unknown.
* `unknown_credential_identifier`: Requested Credential identifier is unknown.
* `invalid_proof`: The `proofs` parameter in the Credential Request is invalid: (1) if the field is missing, or (2) one of the provided key proofs is invalid, or (3) if at least one of the key proofs does not contain a `c_nonce` value (refer to (#nonce-response)).
* `invalid_nonce`: The `proofs` parameter in the Credential Request uses an invalid nonce: at least one of the key proofs contains an invalid `c_nonce` value. The wallet should retrieve a new `c_nonce` value (refer to (#nonce-endpoint)).
* `invalid_nonce`: The `proofs` parameter in the Credential Request uses an invalid nonce: at least one of the key proofs contains an invalid `c_nonce` value. The Wallet should retrieve a new `c_nonce` value (refer to (#nonce-endpoint)).
* `invalid_encryption_parameters`: This error occurs when the encryption parameters in the Credential Request are either invalid or missing. In the latter case, it indicates that the Credential Issuer requires the Credential Response to be sent encrypted, but the Credential Request does not contain the necessary encryption parameters.
* `credential_request_denied`: The Credential Request has not been accepted by the Credential Issuer. The Wallet SHOULD treat this error as unrecoverable, meaning if received from a Credential Issuer the Credential cannot be issued.
* `error_description`: OPTIONAL. The `error_description` parameter MUST be a human-readable ASCII [@!USASCII] text, providing any additional information used to assist the Client implementers in understanding the occurred error. The values for the `error_description` parameter MUST NOT include characters outside the set `%x20-21 / %x23-5B / %x5D-7E`.
Expand Down Expand Up @@ -2641,14 +2641,14 @@ The JWT MUST contain the following elements:
* `kid`: OPTIONAL. JOSE Header containing the key ID. If the Credential is to be bound to a DID, the `kid` refers to a DID URL which identifies a particular key in the DID Document that the Credential is to be bound to. It MUST NOT be present if `jwk` or `x5c` is present.
* `jwk`: OPTIONAL. JOSE Header containing the key material the new Credential is to be bound to. It MUST NOT be present if `kid` or `x5c` is present.
* `x5c`: OPTIONAL. JOSE Header containing at least one certificate where the first certificate contains the key that the Credential is to be bound to, additional certificates may also be present. It MUST NOT be present if `kid` or `jwk` is present.
* `key_attestation`: OPTIONAL. JOSE Header containing a key attestation as described in (#keyattestation). If the Credential Issuer provided a `c_nonce`, the `nonce` claim in the key attestation MUST be set to a server-provided `c_nonce`.
* `key_attestation`: OPTIONAL. JOSE Header containing a key attestation as described in (#keyattestation). If the `nonce` claim is present in the key attestation, its value MUST be set to a server-provided `c_nonce` from the Nonce Endpoint as defined in (#nonce-endpoint). Note that including a `nonce` claim is left to the Wallet. In some environments, a `nonce` is unnecessary because the key material in the `key_attestation` already provides sufficient entropy and freshness. Omitting the `nonce` also enables pre-generation of attestations prior to interacting with a specific Issuer. If the Issuer returns an `invalid_nonce` error, this can be interpreted as an indication that the Issuer expects a `nonce` claim in the `key_attestation`.

@andprian andprian May 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initially there was a suggestion to have a parameter require_nonce_in_key_attestation_in_jwt_proof and I believe that this is necessary to have, otherwise the wallet cannot know what the issuer expects without trial and error.

@andprian andprian May 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this can be interpreted as an indication -> can it be interpreted in another way as well?

@andprian andprian May 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering that the issuer can still enforce the presence of the nonce in the key_attestation, it is not actually true that including a nonce claim is left to the Wallet. Saying this is left to the wallet makes one believe that the request will succeed in both cases.

* `trust_chain`: OPTIONAL. JOSE Header containing an [@!OpenID.Federation] Trust Chain. This element MAY be used to convey key attestation, metadata, metadata policies, federation Trust Marks and any other information related to a specific federation, if available in the chain. When used for signature verification, the header parameter `kid` MUST be present.

* in the JWT body,
* `iss`: OPTIONAL (string). The value of this claim MUST be the `client_id` of the Client making the Credential request. This claim MUST be omitted if the access token authorizing the issuance call was obtained from a Pre-Authorized Code Flow through anonymous access to the token endpoint.
* `aud`: REQUIRED (string). The value of this claim MUST be the Credential Issuer Identifier.
* `iat`: REQUIRED (number). The value of this claim MUST be the time at which the key proof was issued using the syntax defined in [@!RFC7519].
* `nonce`: OPTIONAL (string). The value type of this claim MUST be a string, where the value is a server-provided `c_nonce`. It MUST be present when the issuer has a Nonce Endpoint as defined in (#nonce-endpoint).
* `nonce`: OPTIONAL (string). The value type of this claim MUST be a string, where the value is a server-provided `c_nonce`. It MUST be present when the Issuer has a Nonce Endpoint as defined in (#nonce-endpoint).

The Credential Issuer MUST validate that the JWT used as a proof is actually signed by a key identified in the JOSE Header through either `kid`, `jwk` or `x5c` element.

Expand Down Expand Up @@ -2719,7 +2719,7 @@ When a W3C Verifiable Presentation as defined by [@VC_DATA_2.0] or [@VC_DATA] se
* `cryptosuite`: REQUIRED. If Credential Issuer metadata is provided, the value MUST match one of the entries in the `proof_signing_alg_values_supported` metadata parameter.
* `proofPurpose`: REQUIRED. MUST be set to `authentication`.
* `domain`: REQUIRED. MUST be set to the Credential Issuer Identifier.
* `challenge`: REQUIRED when the Credential Issuer has provided a `c_nonce`. It MUST NOT be used otherwise. String, where the value is a server-provided `c_nonce`. It MUST be present when the issuer has a Nonce Endpoint as defined in (#nonce-endpoint).
* `challenge`: OPTIONAL. The value type of this claim MUST be a string, where the value is a server-provided `c_nonce`. It MUST be present when the Issuer has a Nonce Endpoint as defined in (#nonce-endpoint).

The Credential Issuer MUST validate that the W3C Verifiable Presentation used as a proof is actually signed with a key in the possession of the Holder.

Expand Down Expand Up @@ -2764,7 +2764,7 @@ Below is a non-normative example of a `proofs` parameter (with line breaks withi

A key attestation in JWT format as defined in (#keyattestation-jwt).

If the Credential Issuer has a Nonce Endpoint (as defined in (#nonce-endpoint)), the `c_nonce` value provided by the Credential Issuer MUST be provided in the key attestation's `nonce` parameter.
If the Credential Issuer has a Nonce Endpoint (as defined in (#nonce-endpoint)), the `nonce` claim of the `attestation` MUST be present and set to the `c_nonce` value provided by the Credential Issuer.

Cryptographic algorithm identifiers used in the `proof_signing_alg_values_supported` Credential Issuer metadata parameter for this proof type are case sensitive strings and SHOULD be one of those defined in [@IANA.JOSE].

Expand Down
11 changes: 6 additions & 5 deletions 1.1/openid-4-verifiable-credential-issuance-1_1.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1457,7 +1457,7 @@ If the Wallet is requesting the issuance of a Credential that is not supported b
* `unknown_credential_configuration`: Requested Credential Configuration is unknown.
* `unknown_credential_identifier`: Requested Credential identifier is unknown.
* `invalid_proof`: The `proofs` parameter in the Credential Request is invalid: (1) if the field is missing, or (2) one of the provided key proofs is invalid, or (3) if at least one of the key proofs does not contain a `c_nonce` value (refer to (#nonce-response)).
* `invalid_nonce`: The `proofs` parameter in the Credential Request uses an invalid nonce: at least one of the key proofs contains an invalid `c_nonce` value. The wallet should retrieve a new `c_nonce` value (refer to (#nonce-endpoint)).
* `invalid_nonce`: The `proofs` parameter in the Credential Request uses an invalid nonce: at least one of the key proofs contains an invalid `c_nonce` value. The Wallet should retrieve a new `c_nonce` value (refer to (#nonce-endpoint)).
* `invalid_encryption_parameters`: This error occurs when the encryption parameters in the Credential Request are either invalid or missing. In the latter case, it indicates that the Credential Issuer requires the Credential Response to be sent encrypted, but the Credential Request does not contain the necessary encryption parameters.
* `credential_request_denied`: The Credential Request has not been accepted by the Credential Issuer. The Wallet SHOULD treat this error as unrecoverable, meaning if received from a Credential Issuer the Credential cannot be issued.
* `error_description`: OPTIONAL. The `error_description` parameter MUST be a human-readable ASCII [@!USASCII] text, providing any additional information used to assist the Client implementers in understanding the occurred error. The values for the `error_description` parameter MUST NOT include characters outside the set `%x20-21 / %x23-5B / %x5D-7E`.
Expand Down Expand Up @@ -3209,14 +3209,14 @@ The JWT MUST contain the following elements:
* `kid`: OPTIONAL. JOSE Header containing the key ID. If the Credential is to be bound to a DID, the `kid` refers to a DID URL which identifies a particular key in the DID Document that the Credential is to be bound to. It MUST NOT be present if `jwk` or `x5c` is present.
* `jwk`: OPTIONAL. JOSE Header containing the key material the new Credential is to be bound to. It MUST NOT be present if `kid` or `x5c` is present.
* `x5c`: OPTIONAL. JOSE Header containing at least one certificate where the first certificate contains the key that the Credential is to be bound to, additional certificates may also be present. It MUST NOT be present if `kid` or `jwk` is present.
* `key_attestation`: OPTIONAL. JOSE Header containing a key attestation as described in (#keyattestation). If the Credential Issuer provided a `c_nonce`, the `nonce` claim in the key attestation MUST be set to a server-provided `c_nonce`.
* `key_attestation`: OPTIONAL. JOSE Header containing a key attestation as described in (#keyattestation). If the `nonce` claim is present in the key attestation, its value MUST be set to a server-provided `c_nonce` from the Nonce Endpoint as defined in (#nonce-endpoint). Note that including a `nonce` claim is left to the Wallet. In some environments, a `nonce` is unnecessary because the key material in the `key_attestation` already provides sufficient entropy and freshness. Omitting the `nonce` also enables pre-generation of attestations prior to interacting with a specific Issuer. If the Issuer returns an `invalid_nonce` error, this can be interpreted as an indication that the Issuer expects a `nonce` claim in the `key_attestation`.
* `trust_chain`: OPTIONAL. JOSE Header containing an [@!OpenID.Federation] Trust Chain. This element MAY be used to convey key attestation, metadata, metadata policies, federation Trust Marks and any other information related to a specific federation, if available in the chain. When used for signature verification, the header parameter `kid` MUST be present.

* in the JWT body,
* `iss`: OPTIONAL (string). The value of this claim MUST be the `client_id` of the Client making the Credential request. This claim MUST be omitted if the access token authorizing the issuance call was obtained from a Pre-Authorized Code Flow through anonymous access to the token endpoint.
* `aud`: REQUIRED (string). The value of this claim MUST be the Credential Issuer Identifier.
* `iat`: REQUIRED (number). The value of this claim MUST be the time at which the key proof was issued using the syntax defined in [@!RFC7519].
* `nonce`: OPTIONAL (string). The value type of this claim MUST be a string, where the value is a server-provided `c_nonce`. It MUST be present when the issuer has a Nonce Endpoint as defined in (#nonce-endpoint).
* `nonce`: OPTIONAL (string). The value type of this claim MUST be a string, where the value is a server-provided `c_nonce`. It MUST be present when the Issuer has a Nonce Endpoint as defined in (#nonce-endpoint).

The Credential Issuer MUST validate that the JWT used as a proof is actually signed by a key identified in the JOSE Header through either `kid`, `jwk` or `x5c` element.

Expand Down Expand Up @@ -3287,7 +3287,7 @@ When a W3C Verifiable Presentation as defined by [@VC_DATA_2.0] or [@VC_DATA] se
* `cryptosuite`: REQUIRED. If Credential Issuer metadata is provided, the value MUST match one of the entries in the `proof_signing_alg_values_supported` metadata parameter.
* `proofPurpose`: REQUIRED. MUST be set to `authentication`.
* `domain`: REQUIRED. MUST be set to the Credential Issuer Identifier.
* `challenge`: REQUIRED when the Credential Issuer has provided a `c_nonce`. It MUST NOT be used otherwise. String, where the value is a server-provided `c_nonce`. It MUST be present when the issuer has a Nonce Endpoint as defined in (#nonce-endpoint).
* `challenge`: OPTIONAL. The value type of this claim MUST be a string, where the value is a server-provided `c_nonce`. It MUST be present when the Issuer has a Nonce Endpoint as defined in (#nonce-endpoint).

The Credential Issuer MUST validate that the W3C Verifiable Presentation used as a proof is actually signed with a key in the possession of the Holder.

Expand Down Expand Up @@ -3332,7 +3332,7 @@ Below is a non-normative example of a `proofs` parameter (with line breaks withi

A key attestation in JWT format as defined in (#keyattestation-jwt).

If the Credential Issuer has a Nonce Endpoint (as defined in (#nonce-endpoint)), the `c_nonce` value provided by the Credential Issuer MUST be provided in the key attestation's `nonce` parameter.
If the Credential Issuer has a Nonce Endpoint (as defined in (#nonce-endpoint)), the `nonce` claim of the `attestation` MUST be present and set to the `c_nonce` value provided by the Credential Issuer.

Cryptographic algorithm identifiers used in the `proof_signing_alg_values_supported` Credential Issuer metadata parameter for this proof type are case sensitive strings and SHOULD be one of those defined in [@IANA.JOSE].

Expand Down Expand Up @@ -3685,6 +3685,7 @@ The technology described in this specification was made available from contribut
* use derived origin for `expected_origins` in IAE flow
* add require_interactive_authorization_request to AS metadata
* add interactive_authorization_endpoint to AS metadata section
* Rephrase conditions to provide `nonce` in proof types based on presence of Nonce endpoint
* add invalid_tx_code to Pre-Authz Code Flow
* add URNs for IAE type identifiers
* add iana registration for an openid foundation urn
Loading