- changed status to open
OpenID4VCI: typos in draft 10, Section 1 to 5
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.
Comments (4)
-
-
addresses issue
#1784→ <<cset 862dbe7a6a8f>>
-
Merged in vci-typos (pull request #419)
[ed] Brushes up VCI spec and addresses issue
#1787,#1786,#1620,#1785,#1784Approved-by: Torsten Lodderstedt Approved-by: Michael Jones Approved-by: Jeremie Miller Approved-by: David Waite
→ <<cset c79b4bfa178b>>
-
- changed status to resolved
externalized one residual comment to Issue
#1800 - Log in to comment
PR #419:
two comments - I think using server to server communication is correct.. - why is Authorization Request a GET?