From 90d84d9f7360257a40d76a45bd9b8049bc43772a Mon Sep 17 00:00:00 2001 From: Jim Marino Date: Fri, 15 Mar 2024 14:40:28 +0100 Subject: [PATCH 1/2] token rename --- specifications/credential.issuance.protocol.md | 4 ++-- specifications/identity-trust-sts-api.yaml | 6 +++--- specifications/identity.protocol.base.md | 12 ++++++------ specifications/testing/base_tests.md | 2 +- specifications/testing/credentialservice.md | 6 +++--- specifications/testing/verifier.md | 2 +- specifications/verifiable.presentation.protocol.md | 2 +- 7 files changed, 17 insertions(+), 17 deletions(-) diff --git a/specifications/credential.issuance.protocol.md b/specifications/credential.issuance.protocol.md index 2ed2c77..1b540e9 100644 --- a/specifications/credential.issuance.protocol.md +++ b/specifications/credential.issuance.protocol.md @@ -66,11 +66,11 @@ the [Base Identity Protocol Specification](identity.protocol.base.md#411-vp-acce used by the Credential Issuer to resolve the client's DID to obtain cryptographic material for validation and credential binding. -The ID Token MUST contain a `access_token` claim that is a bearer token granting write privileges for the +The ID Token MUST contain a `token` claim that is a bearer token granting write privileges for the requested VCs into the client's `Credential Service` as defined by the [Verifiable Presentation Protocol specification](verifiable.presentation.protocol.md) -The ID Token MAY contain an `access_token` claim as defined in +The ID Token MAY contain an `token` claim as defined in the [Base Identity Protocol Specification](identity.protocol.base.md) claim that can be used by the issuer to resolve Verifiable Presentations (VP) the client is required to hold for issuance of the requested VCs. diff --git a/specifications/identity-trust-sts-api.yaml b/specifications/identity-trust-sts-api.yaml index 9ba1e58..b2d89e1 100644 --- a/specifications/identity-trust-sts-api.yaml +++ b/specifications/identity-trust-sts-api.yaml @@ -7,7 +7,7 @@ paths: content: application/x-www-form-urlencoded: encoding: - access_token: + token: style: form audience: style: form @@ -20,7 +20,7 @@ paths: schema: type: object properties: - access_token: + token: type: string description: VP access token to be added as a claim in the SI token audience: @@ -72,7 +72,7 @@ components: StsTokenResponse: type: object properties: - access_token: + token: type: string expires_in: type: integer diff --git a/specifications/identity.protocol.base.md b/specifications/identity.protocol.base.md index 255347c..78a5430 100644 --- a/specifications/identity.protocol.base.md +++ b/specifications/identity.protocol.base.md @@ -78,8 +78,8 @@ include the following claims: ## 4.1.1. VP Access Token -A Self-Issued ID Token MAY contain an access token as an `access_token` claim that can be used by the relying party to -obtain additional VPs from a service under the control of the ID token issuer. The format of the `access_token` is +A Self-Issued ID Token MAY contain an access token as a `token` claim that can be used by the relying party to +obtain additional VPs from a service under the control of the ID token issuer. The format of the `token` is implementation-specific and therefore must be treated as an opaque string by the relying party. > TODO: determine claim name @@ -102,14 +102,14 @@ an [OAuth 2.0 Client Credential Grant](https://www.rfc-editor.org/rfc/rfc6749.ht Service (STS) Endpoint. How the participant agent obtains the endpoint address is implementation-specific and beyond the scope of this specification. -If an `access_token` is required to be included in the Self_issued ID token, the participant agent will need to request +If an `token` is required to be included in the Self_issued ID token, the participant agent will need to request scopes for the access token. This is dependent on the API used to obtain the Self-Issued ID Token. An STS implementation MAY use endpoint parameters as defined by the [OAuth 2 specification](https://www.rfc-editor.org/rfc/rfc6749.html#section-8.2) to convey metadata necessary for -the creation of the `access_token` claim. In this case, the Self-Issued ID Token request MAY contain +the creation of the `token` claim. In this case, the Self-Issued ID Token request MAY contain a `bearer_access_scope` authorization request parameter set to a -list of space-delimited scopes the `access_token` claim will be enabled for. If no `bearer_access_scope` parameter is -present, the `access_token` claim MUST not be included. +list of space-delimited scopes the `token` claim will be enabled for. If no `bearer_access_scope` parameter is +present, the `token` claim MUST not be included. > A non-normative OpenAPI spec of an STS implementing client credentials flow is > provided [here](identity-trust-sts-api.yaml) diff --git a/specifications/testing/base_tests.md b/specifications/testing/base_tests.md index e6a945b..987d729 100644 --- a/specifications/testing/base_tests.md +++ b/specifications/testing/base_tests.md @@ -119,7 +119,7 @@ Might need to move this into another document ## Validating SI tokens as the relying party This section outlines tests that need to be passed on the _relying side_, when receiving Self-issued ID -tokens that contain an `access_token`. +tokens that contain a `token`. Please read details [here](./verifier.md) ## Validating SI tokens in the CredentialService diff --git a/specifications/testing/credentialservice.md b/specifications/testing/credentialservice.md index 7cbdd24..78f157e 100644 --- a/specifications/testing/credentialservice.md +++ b/specifications/testing/credentialservice.md @@ -10,7 +10,7 @@ This document deals with tests for the CredentialService. The system-under-test, i.e. the execution runtime of the CredentialService, is regarded as a black box, exposing only the Resolution API. The test harness then executes REST requests against that API and performs test assertions. It may be -necessary for the test harness to interact with the system-under-test, e.g. to obtain valid `presentation_access_tokens` +necessary for the test harness to interact with the system-under-test, e.g. to obtain a valid `token` or to prepare a specific (set of) VCs. ## Verifying/Validating incoming SI Token requests @@ -27,9 +27,9 @@ below._ | P_0003 | Signature invalid | The signature of the JWT can not be verified using the public key from the counterparty. | | P_0004 | `sub_jwk` must not be present | The JWT contains a `sub_jwk` claim | | P_0005 | `jti` already used | The same `jti` claim value was used twice within the token's expiry time | -| P_0006 | `presentation_access_token` must be present | The JWT must contain a `presentation_access_token` claim, the shape of which is opaque | +| P_0006 | `token` must be present | The JWT must contain a `token` claim, the shape of which is opaque | | P_0007 | `client_id` must be present | The JWT must contain a `client_id` claim, that must be identical to the sender's participant ID | -| P_0008 | Issuer's scope not valid | The `presentation_access_token` cannot be resolved to a valid scope. That means, the scope string that is encoded in the token is invalid or is not understood. | +| P_0008 | Issuer's scope not valid | The `token` cannot be resolved to a valid scope. That means, the scope string that is encoded in the token is invalid or is not understood. | | P_0009 | Requestor's query not valid | The `scope` or `presentationDefinition` object of the presentation query cannot be parsed to valid scope string. | | P_0010 | Requestor's query is unauthorized | The requestor is not authorized for at least one item specified by the query. In practice, this could be a scope string that is "too wide" | diff --git a/specifications/testing/verifier.md b/specifications/testing/verifier.md index 67e6b0d..141d429 100644 --- a/specifications/testing/verifier.md +++ b/specifications/testing/verifier.md @@ -22,7 +22,7 @@ outgoing VP query request from the verifier, respectively. The test harness will | R_0001 | Signature invalid | The signature of the JWT can not be verified using the public key from the counterparty. | | | R_0002 | `sub_jwk` must not be present | The JWT contains a `sub_jwk` claim | | | R_0003 | `jti` already used | The same `jti` claim value was used twice within the token's expiry time | | -| R_0004 | `presentation_access_token` must be present | The JWT must contain a `presentation_access_token` claim, the shape of which is opaque | | +| R_0004 | `token` must be present | The JWT must contain a `token` claim, the shape of which is opaque | | | R_0005 | `client_id` must be present | The JWT must contain a `client_id` claim, that must be identical to the sender's participant ID | | ## Validating VerifiablePresentation responses diff --git a/specifications/verifiable.presentation.protocol.md b/specifications/verifiable.presentation.protocol.md index 5f1aa79..83f401a 100644 --- a/specifications/verifiable.presentation.protocol.md +++ b/specifications/verifiable.presentation.protocol.md @@ -114,7 +114,7 @@ including requiring the requester to present its own VPs. # 3.2.1 Submitting an Access Token Implementations that support access control require an access token. To provide the opportunity for `Credential Service` -implementations to enforce proof-of-possession, the access token MUST be contained in the `access_token` +implementations to enforce proof-of-possession, the access token MUST be contained in the `token` claim of a self-issued identity token as defined in [Base Identity Protocol Section 4](identity.protocol.base.md#4-self-issued-id-tokens). The self-issued token MUST be submitted in the HTTP `Authorization` header prefixed with `Bearer` of the request. From adad3737aab1fb6033f1b7b3c9b44d512538129e Mon Sep 17 00:00:00 2001 From: Jim Marino Date: Fri, 15 Mar 2024 15:06:05 +0100 Subject: [PATCH 2/2] Revert name change in response --- specifications/identity-trust-sts-api.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specifications/identity-trust-sts-api.yaml b/specifications/identity-trust-sts-api.yaml index b2d89e1..75ea264 100644 --- a/specifications/identity-trust-sts-api.yaml +++ b/specifications/identity-trust-sts-api.yaml @@ -72,7 +72,7 @@ components: StsTokenResponse: type: object properties: - token: + access_token: type: string expires_in: type: integer