Skip to content

Commit

Permalink
Merge pull request #52 from jimmarino/feature/access-token-rename
Browse files Browse the repository at this point in the history
Rename `access_token` to `token` per previous discussions
jimmarino authored Mar 15, 2024
2 parents 1341a06 + adad373 commit 5db571f
Showing 7 changed files with 16 additions and 16 deletions.
4 changes: 2 additions & 2 deletions specifications/credential.issuance.protocol.md
Original file line number Diff line number Diff line change
@@ -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.

4 changes: 2 additions & 2 deletions specifications/identity-trust-sts-api.yaml
Original file line number Diff line number Diff line change
@@ -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:
12 changes: 6 additions & 6 deletions specifications/identity.protocol.base.md
Original file line number Diff line number Diff line change
@@ -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)
2 changes: 1 addition & 1 deletion specifications/testing/base_tests.md
Original file line number Diff line number Diff line change
@@ -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
6 changes: 3 additions & 3 deletions specifications/testing/credentialservice.md
Original file line number Diff line number Diff line change
@@ -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" |

2 changes: 1 addition & 1 deletion specifications/testing/verifier.md
Original file line number Diff line number Diff line change
@@ -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
2 changes: 1 addition & 1 deletion specifications/verifiable.presentation.protocol.md
Original file line number Diff line number Diff line change
@@ -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.

0 comments on commit 5db571f

Please sign in to comment.