[Openid-specs-ab] Issue #1787: OpenID4VCI: typos in draft 10, Appendix D to Appendix E (openid/connect)

[Takahiko Kawasaki]

New issue 1787: OpenID4VCI: typos in draft 10, Appendix D to Appendix E
https://bitbucket.org/openid/connect/issues/1787/openid4vci-typos-in-draft-10-appendix-d-to

Takahiko Kawasaki:

### E.1.1.2. Server Metadata, the section title

Server Metadata → Credentials Object Parameters \(or something better\)

### E.1.1.2. Server Metadata, the 1st paragraph

The following additional server metadata → The following additional parameters

### E.1.1.2. Server Metadata, name and locale

The descriptions about `name` and `locale` in `credentialSubject` should be indented properly.

### E.1.1.2. Server Metadata, the example

`"alternative_text"` → `"alt_text"`

### E.1.1.3. Credential Offer, the 1st bullet \(types\)

values the wallet shall → values the Wallet shall

### E.1.1.4. Authorization Deails, the section title

Deails → Details

### E.1.1.4. Authorization Deails, the 1st bullet \(types\)

REQUIRED. as defined → REQUIRED as defined

values the wallet requests → values the Wallet requests

### E.1.1.4. Authorization Deails, the 2nd bullet \(credentialSubject\)

indicates the claims the wallet would → indicates the claims the Wallet would

### E.1.1.4. Authorization Deails, the example

`"CredentialSubject"` → `"credentialSubject"`

Remove the comma \(`,`\) after `"degree": {}`.

### E.1.1.5. Credential Request, the 1st bullet \(types\)

REQUIRED. as defined → REQUIRED as defined

### E.1.1.5. Credential Request, the 2nd bullet \(credentialSubject\)

OPTIONAL. as defined → OPTIONAL as defined

### E.1.1.6. Credential Response, the 1st paragraph

> The value of the `credential` claim in the credential response MUST be a JSON String.

If “credential response” is used without capitalization like this and it is allowed, occurrences of “Credential Response” in the document should be changed so, too.

a JSON String → a JSON string

### E.1.1.6. Credential Response, the 2nd paragraph

> The following is a non-normative example of a credential issuance response with Credential format `jwt_vc_json`.

If “credential issuance response” is used without capitalization like this and it is allowed, occurrences of “Credential Issuance Response” in the document should be changed so, too.

### E.1.2.2. Server Metadata, the section title

Server Metadata → Credentails Object Parameters \(or something better\)

### E.1.3.2. Server Metadata, the section title

Server Metadata → Credentials Object Parameters \(or something better\)

### E.1.3.2. Server Metadata, the 1st paragraph

The following additional server metadata → The following additional parameters

### E.1.3.2. Server Metadata, name and locale

The descriptions about `name` and `locale` in `credentialSubject` should be indented properly.

### E.1.3.2. Server Metadata, the example

`"alternative_text"` → `"alt_text"`

### E.1.3.3. Credential Offer, the bullet for `@context`

REQUIRED. as defined → REQUIRED as defined

### E.1.3.3. Credential Offer, the bullet for types

REQUIRED. as defined → REQUIRED as defined

values the wallet shall → values the Wallet shall

### E.1.3.4. Authorization Deails, the section title

Deails → Details

### E.1.3.4. Authorization Deails, the bullet for credential\_definition

REQUIRED. as defined → REQUIRED as defined

### E.1.3.4. Authorization Deails, the example

`"CredentialSubject"` → `"credentialSubject"`

### E.1.3.5. Credential Request, the bullet for credential\_definition

REQUIRED. as defined → REQUIRED as defined

### E.2.2. Server Metadata, the section title

Server Metadata → Credentials Object Parameters \(or something better\)

### E.2.2. Server Metadata, the 1st paragraph

The following additional server metadata → The following additional parameters

### E.2.2. Server Metadata, name and locale

The descriptions about `name` and `locale` in `claims` should be indented properly.

### E.2.2. Server Metadata, the example

`"ES256, ES384, ES512"` → `"ES256", "ES384", "ES512"`

`"alternative_text"` → `"alt_text"`

`"locale": "jp-JA"` → `"locale": "ja-JP"`

### E.2.3. Credential Offer, the 1st bullet \(doctype\)

REQUIRED. as defined → REQUIRED as defined

### E.2.3. Credential Offer, the 2nd paragraph

example of an Credential Offer → example of a Credential Offer

### E.2.4. Authorization Details, the 1st bullet \(doctype\)

REQUIRED. as defined → REQUIRED as defined

### E.2.4. Authorization Details, the 2nd bullet \(claims\)

OPTIONAL. as defined → OPTIONAL as defined

### E.2.5. Credential Request, the 1st bullet \(doctype\)

REQUIRED. as defined → REQUIRED as defined

### E.2.5. Credential Request, the 2nd bullet \(claims\)

OPTIONAL. as defined → OPTIONAL as defined

### E.2.6. Credential Response, the 1st paragraph

MUST be a a JSON string → MUST be a JSON string

---

Inconsistency in using uppercase and lowercase letters. Not only technical terms defined in this specification but also common nouns such as “JSON Object” vs “JSON object”. This inconsistency, as complained in a past WG call \(about the SIOPv2 specification\), makes the specification hard to read and makes people question the quality of the specification \(and actually the quality is low as even examples contain many errors\). Too indifferent to the difference between uppercase and lowercase letters.

A professional proofreader will be needed so that this specification can win among competing specifications.