Merge pull request #24 from jimmarino/feature/token-namespace

Fully qualify data address extensions

tx/refresh/refresh.token.grant.profile.md

@@ -24,7 +24,8 @@ When starting a transfer process, an `access token` may be generated by the prov
 and returned in the `DataAddress` part of the
 DSP [TransferStartMessage](https://docs.internationaldataspaces.org/ids-knowledgebase/v/dataspace-protocol/transfer-process/transfer.process.protocol#id-2.2-transfer-start-message).
 
-This profile adds three additional `EndpopintProperties` to the `DataAddress`:
+This profile adds three additional `EndpopintProperties` to the `DataAddress` under the `https://w3id.org/tractusx/auth`
+context:
 
 - `refreshToken` - OPTIONAL: An opaque string clients must present when requesting token renewal.
 - `expiresIn` - REQUIRED if `refreshToken` is present: The lifetime in seconds of the `accessToken` as defined by
@@ -46,23 +47,23 @@ The following is a non-normative example of a `TransferStartMessage` message con
     "dspace:endpoint": "https://example.com",
     "dspace:endpointProperties": [
       {
-        "dspace:name": "authorization",
+        "dspace:name": "https://w3id.org/edc/v0.0.1/ns/authorization",
         "dspace:value": "TOKEN-ABCDEFG"
       },
       {
-        "dspace:name": "authType",
+        "dspace:name": "https://w3id.org/edc/v0.0.1/ns/authType",
         "dspace:value": "bearer"
       },
       {
-        "dspace:name": "refreshToken",
+        "dspace:name": "https://w3id.org/tractusx/auth/refreshToken",
         "dspace:value": "REFRESH-TOKEN-ABCDEFG"
       },
       {
-        "dspace:name": "expiresIn",
+        "dspace:name": "https://w3id.org/tractusx/auth/expiresIn",
         "dspace:value": "300"
       },
       {
-        "dspace:name": "refreshEndpoint",
+        "dspace:name": "https://w3id.org/tractusx/auth/refreshEndpoint",
         "dspace:value": "https://example.com/authorization/refresh"
       }
     ]
@@ -102,12 +103,15 @@ following specifications:
   used to verify the JWT.
 - The `iss` claim is set to the client's `DID`.
 - The `sub` claim is set to the client's `DID`.
-- A `access_token` contains the access token associated with the refresh token.
+- A `token` claim contains the access token associated with the refresh token.
 - The JWT is signed using the private key associated with the key material specified by the `kid` header parameter.
 
-The consumer client SHOULD acknowledge refresh token rotation which might lead to revocation of the refresh token in case of subsequent 
-requests with the same refresh token. In that case the client should implement a mechanism to prevent redundant usage of the same refresh 
-token and instead use the refresh token after the rotation. An expired or revoked refresh token might lead to transfer process termination.
+The consumer client SHOULD acknowledge refresh token rotation which might lead to revocation of the refresh token in
+case of subsequent
+requests with the same refresh token. In that case the client should implement a mechanism to prevent redundant usage of
+the same refresh
+token and instead use the refresh token after the rotation. An expired or revoked refresh token might lead to transfer
+process termination.
 
 ### 3.2. Provider Request Validation