token rename

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.
 

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

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)

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

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"                                |
 

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

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.