[Openid-specs-ab] Issue #1784: OpenID4VCI: typos in draft 10, Section 1 to 5 (openid/connect)

[Takahiko Kawasaki]

New issue 1784: OpenID4VCI: typos in draft 10, Section 1 to 5
https://bitbucket.org/openid/connect/issues/1784/openid4vci-typos-in-draft-10-section-1-to

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.

‌