OpenID4VCI: typos in draft 10, Section 6 to 7

[Takahiko Kawasaki]

6. Token Endpoint, the 1st paragraph

The Token Endpoint issues an Access Token and, optionally, a Refresh Token in exchange for the authorization code that client obtained in a successful Authorization Response.

It would be worth considering minimizing use of capitalized technical terms in the middle of sentences in the overall document. “Token Endpoint”, “Access Token”, “Refresh Token” and “Authorization Response” in one sentence are too much.

6.1. Token Request, the 3rd paragraph (the paragraph after the 2nd bullet)

depend on the grant type → depends on the grant type

6.1. Token Request, the 4th paragraph

as as described → as described

6.1 Token Request, the 6th paragraph

If the token request contains an …

If “token request” is used like this (it’s natual), all occurrences of “Token Request” should be decapitalized.

6.1. Token Request, the 1st token request example

An empty line should be inserted between the header part and the body part.

6.2. Token Response, the 1st paragraph

Token Requests are made → Token Responses are made

6.2. Token Response, the 2nd bullet (c_nonce)

When received,the wallet → When received, the Wallet

6.2. Token Response, the 3rd bullet (authorization_pending)

the “interval” response parameter → the interval response parameter

6.3. Token Error Response, the 3rd bullet (invalid_client)

client id → client ID

6.3. Token Error Response, the token error response example

An empty line should be inserted between the header part and the body part.

7.1. Binding the Issued Credential to the identifier of the End-User possessing that Credential, the 1st paragraph

to verify during presentation → to verify the presentation

see Implementations Considerations → see Implementation Considerations

7.2. Credential Request, the 2nd bullet (proof)

type JSON denoting → type JSON string denoting

7.2.1. Proof Types, the last bullet (nonce)

provided by the credential issuer

If “credential issuer” is used like this and allowed, it’s worth considering replacing occurences of “Credential Issuer” in the document with “credential issuer” whenever applicable. (Or simply change the “credential issuer” here to “Credential Issuer”.)

7.3. Credential Response, the 4th bullet (c_nonce)

When received,the wallet → When received, the Wallet

7.3. Credential Response, the 1st credential response example

Append a comma (,) after "format": "jwt_vc_json".

7.3.1. Credential Error Response, invalid_request

(.i.e. format, proof)are missing → (.i.e. format, proof) are missing

malformatted → malformed

7.3.2. Credential Issuer Provided Nonce, the credential response example

Append a comma (,) after (1) the value of "error" and (2) the value of "error_description".

‌

---

HTTP headers in examples should be aligned properly. For example,

HTTP/1.1 400 Bad Request
  Content-Type: application/json
  Cache-Control: no-store

should be

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

‌

[Kristina Yasuda]

Addressed in PR #419.

two comments..

1.

“Token Endpoint”, “Access Token”, “Refresh Token” and “Authorization Response” in one sentence are too much.

Below is literally a sentence from OIDC.Core.

To obtain an Access Token, an ID Token, and optionally a Refresh Token, the RP (Client) sends a Token Request to the Token Endpoint to obtain a Token Response, as described in Section 3.2 of OAuth 2.0 [RFC6749], when using the Authorization Code Flow.

2. Below was correct. I clarified the sentence

to verify during presentation → to verify the presentation

‌

[Torsten Lodderstedt]

Merged in vci-typos (pull request #419)

[ed] Brushes up VCI spec and addresses issue #1787, #1786, #1620, #1785, #1784

Approved-by: Torsten Lodderstedt Approved-by: Michael Jones Approved-by: Jeremie Miller Approved-by: David Waite

→ <<cset c79b4bfa178b>>