From ea153bc2a541aac7d8580814330ee7e34fd3d9c4 Mon Sep 17 00:00:00 2001 From: Tobias Looker Date: Fri, 29 Nov 2024 12:02:34 +1300 Subject: [PATCH] minor tweaks to language --- openid-4-verifiable-credential-issuance-1_0.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index cfcdac9f..0b96804c 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -774,12 +774,10 @@ Content-Length: 0 The Credential Issuer provides a nonce value in the HTTP response with a 2xx status code and the following parameters included as top-level members in the message body of the HTTP response using the application/json media type: -* `c_nonce`: REQUIRED. String containing a nonce to be used when creating a proof of possession of the key proof (see (#credential-request)). +* `c_nonce`: REQUIRED. String containing a nonce to be used when creating a proof of possession of the key proof (see (#credential-request)). This value MUST be unpredictable and unique for every response returned from the nonce endpoint. Due to the temporal and contextually sensitive nature of the `c_nonce` value, the Credential Issuer MUST make the response uncacheable by adding a `Cache-Control` header field including the value `no-store`. -A wallet SHOULD assume that the returned `c_nonce` value remains valid and continue using it in credential requests (see [#credential-request]) until the credential endpoint returns an `invalid_nonce` error response. - Below is a non-normative example of a Nonce Response: ```