feat: clarify wording on tokens

specifications/auth.flow.puml

@@ -16,13 +16,13 @@ box "Verifier Entity"
 participant "Verifier" as V
 end box
 
-C -> STS: SI token request
-STS -> C: Token response w/ access token
+C -> STS: request
+STS -> C: response incl. access token
 
-C -> V: Request w/ Self-Issued ID token containing an access token
-DS <- V: Resolve DID
+C -> V: request w/ self-issued id token incl. access token
+DS <- V: resolve DID
 DS -> V: DID document response
-CS <- V: request w/ access token
+CS <- V: request w/ self-issued id token incl. access token
 CS ->V: VP response
-C <- V: Response
-@enduml
+C <- V: response
+@enduml

specifications/credential.issuance.protocol.md

@@ -9,17 +9,18 @@ where a manual workflow is required.
 The following sequence diagram depicts a non-normative flow where a client interacts with a [=Credential Issuer=] to
 issue a [=Verifiable Credential=]:
 
-![Issuance Flow](specifications/issuance.flow.png "Issuance Flow")
-
-1. The client sends a request to its [=Secure Token Service=] for a [=Self-Issued ID Token=]. The API used to make this
-   request is implementation specific. The client may include a set of scopes that define the [=Verifiable Credentials=]
-   the client wants the [=Issuer Service=] to provide. This set of scopes is determined out of band and may be derived
-   from metadata the [=Credential Issuer=] has previously made available to the client.
-2. The [=Secure Token Service=] responds with the Self-Signed ID token containing a `token` claim with the value set to
-   an access token. The access token can be used by the [=Issuer Service=] to write requested [=Verifiable Credentials=]
+![Issuance Flow](specifications/issuance.flow.svg "Issuance Flow")
+
+1. The client sends a request to its [=Secure Token Service=] for a token including an access token. This could be a
+   [=Self-Issued ID Token=]. The API used to make this request is implementation specific. The client may include a set
+   of scopes that define the [=Verifiable Credentials=] the client wants the [=Issuer Service=] to provide. This set of
+   scopes is determined out of band and may be derived from metadata the [=Credential Issuer=] has previously made
+   available to the client.
+2. The [=Secure Token Service=] responds with an access token a that may be in `token` claim a [=Self-Issued ID Token=].
+   The access token can be used by the [=Issuer Service=] to write requested [=Verifiable Credentials=]
    to the client's [=Credential Service=].
 3. The client makes a request to the [=Issuer Service=] for one or more [=Verifiable Credentials=] and includes
-   the [=Self-Issued ID Token=].
+   a [=Self-Issued ID Token=] containing the access token.
 4. The [=Issuer Service=] resolves the client [=DID=] based on the value of the [=Self-Issued ID Token=] `sub` claim.
 5. The [=DID Service=] returns the DID Document. The [=Issuer Service=] validates the [=Self-Issued ID Token=] following
    Section [[[#validating-self-issued-id-tokens]]].

specifications/issuance.flow.puml

@@ -16,14 +16,13 @@ box "Issuer Entity"
 participant "Issuer Service" as IS
 end box
 
-C -> STS: Self-Issued ID token request
-STS -> C: Token response w/ access token
-C -> IS: Request credential(s) using Self-Issued ID token
-DS <- IS: Resolve DID
+C -> STS: request
+STS -> C: response incl. access token
+C -> IS: request credential(s) w/ self-issued ID token incl. access token
+DS <- IS: resolve DID
 DS -> IS: DID document response
-C <- IS: Ack
-CS <- IS: (async) Write credential(s)\n w/ access token
+C <- IS: ack
+CS <- IS: (async) write credential(s)\n w/ self-issued ID token access token
 CS -> CS: Validate token and\n store credentials
 
-
 @enduml