OpenID4VCI: typos in draft 10, Section 1 to 5

[Takahiko Kawasaki]

2. Terminology, Wallet

locally by the end-user → locally by the End-User

3.2. OAuth 2.0, the last bullet (Token Endpoint)

the Credential endpoint → the Credential Endpoint

3.3. Core Concepts, the 1st paragraph

The wallet MAY → The Wallet MAY

3.3. Core Concepts, the paragraph after the 4th bullet

authenticate or identify the User → authenticate or identify the End-User

3.3. Core Concepts, the paragraph after the 6th bullet

at each extensibility point → at each extension point

above-mentioned extensibility points → above-mentioned extension points

3.4. Authorized Code Flow, the section titile

Authorized Code Flow → Authorization Code Flow

3.4. Authorized Code Flow, (1)

via the user agents → via the user agent

3.4. Authorized Code Flow, (2)

The paragraph says “the authorization code obtained in step (2)”, but the diagram does not contain “(2)”.

3.4. Authorized Code Flow, (2)

using server to server communication → using client to server communication

3.4. Authorized Code Flow, the paragraph after (3)

may returns → may return

3.4. Authorized Code Flow, the last paragraph

the code grant type → the authorization code grant type

3.5. Pre-Authorized Code Flow, (1)

generates an Credential Offer → generates a Credential Offer

3.5. Pre-Authorized Code Flow, (2)

The underscore in “pre-authorized_code” needs to be escaped properly. Otherwise, it is interpreted as a mark to start “font-style:italic”.

4.1. Credential Offer

a HTTP GET → an HTTP GET

a HTTP redirect → an HTTP redirect

that contains an Credential Offer object → that contains a Credential Offer object

4.1. Credential Offer, the 2nd bullet (credentials)

the wallet MUST resolve → the Wallet MUST resolve

4.1. Credential Offer, the 3rd bullet (grants)

the wallet → the Wallet (at multiple places)

the credential issuer → the Credential Issuer (at multiple places)

4.1. Credential Offer, issuer_state

sub-sequent → subsequent

If the wallet decides → If the Wallet decides

4.1. Credential Offer, pre-authorized_code

If the wallet decides → If the Wallet decides

MUST be include in the sub-sequent → MUST be included in the subsequent

4.1. Credential Offer, user_pin_required

If the wallet decides → If the Wallet decides

4.1. Credential Offer, the paragraph before the 1st credential offer object example

example of an Credential Offer → example of a Credential Offer

4.1. Credential Offer, the 3rd paragraph after the 3rd credential offer object example

in this draft → in this specification

4.1. Credential Offer, the paragraph before the 1st credential offer request example

example of an Credential Offer → example of a Credential Offer

5.1. Authorization Request, the 1st paragraph

A Authorization Request → An Authorization Request

Credential endpoint → Credential Endpoint

5.1. Authorization Request, the 2nd paragraph

a Authorization Request → an Authorization Request

5.1.1. Request Issuance of a Certain Credential Type using authorization_details Parameter, the 1st paragraph

The request parameter authorization_type → The request parameter authorization_details

5.1.1. Request Issuance of a Certain Credential Type using authorization_details Parameter, the paragraph before the authorization request example

example of a Authorization Request → example of an Authorization Request

5.1.1. Request Issuance of a Certain Credential Type using authorization_details Parameter, the authorization request example

The example starts with HTTP/1.1 302 Found and uses the Location header. It should start with GET and use the Host header, instead. (unless the specification assumes that an authorization request is typically triggered by an HTTP redirection.)

5.1.2. Using scope Parameter to Request Issuance of a Credential, the 3rd paragraph

collision-resistant scopes values → collision-resistant scope values

5.1.2. Using scope Parameter to Request Issuance of a Credential, the 5th paragraph

Providers that do not understand the value of this scope in a request MUST ignore it entirely. → Providers MUST ignore unknown scope values in a request.

5.1.2. Using scope Parameter to Request Issuance of a Credential, the paragraph before the authorization request example

example of a Authorization Request → example of an Authorization Request

5.1.2. Using scope Parameter to Request Issuance of a Credential, the authorization request example

The example starts with HTTP/1.1 302 Found and uses the Location header. It should start with GET and use the Host header, instead. (unless the specification assumes that an authorization request is typically triggered by an HTTP redirection.)

5.1.2. Using scope Parameter to Request Issuance of a Credential, the last paragraph

than → then

5.1.3. Additional Request Parameters, the 1st paragraph

a Authorization Request → an Authorization Request

5.1.5. Dynamic Credential Request, the 2nd paragraph

It is RECOMMENDED that the Credential Issuer uses → It is RECOMMENDED that the Credential Issuer use

5.1.5. Dynamic Credential Request, the 3rd paragraph

the end-user’s Wallet → the End-User’s Wallet

---

• Do not repeat misuse of indefinite articles (“a” and “an”).
• Overworked capitalized terms and occasional occurrences of all-lowercase terms (i.e. inconsistent use) make the specification hard to read and make people question the quality of the sepcification. Unlike German, in English common nouns are all lower case except at the beginning of a sentence.

‌

[Kristina Yasuda]

PR #419:

two comments - I think using server to server communication is correct.. - why is Authorization Request a GET?

[Kristina Yasuda]

addresses issue #1784

→ <<cset 862dbe7a6a8f>>

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

[Kristina Yasuda]

externalized one residual comment to Issue #1800