- edited description
SIOP: typos in draft 12, from Abstract to Section 7
Abstract, the 2nd paragraph
Instead the End-user → Instead the End-User
// Capitalize “u” in “End-user”.
under the End-user’s control → under the End-User’s control
// Capitalize “u” in “End-user’s”.
1. Introduction, the 2nd paragraph
End-user control does not → End-User control does not
// Capitalize “u” in “End-user”.
hosted on an End-user’s device → hosed on an End-User’s device
// Capitalize “u” in “End-user’s”.
run on a End-user device → run on an End-User’s device
// a → an, End-user → End-User’s
1. Introduction, the 3rd paragraph
allows the End-user → allows the End-User
// Capitalize “u” in “End-user”.
1.2. Terms and Definitions, Self-Issued OpenID Provider
used by the End-users → user by the End-User | used by End-Users
// Change “the End-users” to “the End-User” or “End-Users”.
1.2. Terms and Definitions, Wallet
locally by the end-user → locally by the End-User
// Capitalize “e” and “u” in “end-user”.
2.1. In Scope, Support for Self-Asserted Claims
Append a period at the end of the sentence.
2.2.1. Presentation of Claims from the Third-Party Issuers, the 2nd paragraph
sources is → sources are
// Change “is” to “are”. (The subject of the sentence is “Methods”.)
2.3. Relationship with Section 7 of [OpenID.Core] Self-Issued OpenID Provider, the 5th bullet
the custom URL schemas → the custom URL scheme
// Change “schemas” to “scheme”.
3. Protocol Flow, Figure 1
The 4th line of the box representing Self-Issued OP is a bit broken. One white space should be added between “(Authorization Request)” and the left pipe (|
) of the box.
4. Cross-Device Self-Issued OP, the 5th numbered bullet
a HTTP POST request → an HTTP POST request
// Change “a” to “an”.
5. Self-Issued OpenID Provider Invocation, the 1st paragraph
When the End-user → When the End-User
// Capitalize “u” in “End-user”.
an End-user may have → an End-User may have
// Capitalize “u” in “End-user”.
5. Self-Issued OpenID Provider Invocation, the 3rd paragraph
End-user scans → End-User scans
// Capitalize “u” in “End-user”.
5. Self-Issued OpenID Provider Invocation, the 4th paragraph
how RP can obtain → how the RP can obtain
// Insert “the”.
5. Self-Issued OpenID Provider Invocation, the 5th paragraph
opened by the End-user → opened by the End-User
// Capitalize “u” in “End-user”.
6. Self-Issued OpenID Provider Discovery, the 1st paragraph
RP can obtain → The RP can obtain
// Insert “The”.
6.1. Dynamic Discovery of Self-Issued OpenID Provider Metadata, the 5th paragraph
These OpenID Provider Metadata values are used by the Self-Issued OP → These Self-Issued OP Metadata values are used by the RP.
// Change “OpenID Provider” to “Self-Issued OP” and “Self-Issued OP” to “RP”.
6.1. Dynamic Discovery of Self-Issued OpenID Provider Metadata, subject_syntax_types_supported
JWK Thumbprint, valid value is → JWK Thumbprint, a valid value is
// Insert “a”.
by sending did without any method-name → by sending did
without any method-name
// Change “did” to “did
“.
6.1. Dynamic Discovery of Self-Issued OpenID Provider Metadata, subject_signed_id_token
i.e. the id token is signed → i.e. the ID Token is signed
// Change “id token” to “ID Token”.
6.1. Dynamic Discovery of Self-Issued OpenID Provider Metadata, attester_signed_id_token
the id token is issued → the ID Token is issued
// Change “id token” to “ID Token”.
the classical id token → the classical ID Token
// Change “id token” to “ID Token”.
7. Relying Party Registration, the 1st paragraph
obtain RP’s metadata → obtain the RP’s metadata
// Insert “the”.
7. Relying Party Registration, the 1st bullet
e.g using → e.g. using
// Insert a period.
7. Relying Party Registration, the 2nd bullet
RP provides → The RP provides
// Add “The” at the beginning.
OpenID Federation 1.0 → OpenID Connect Federation 1.0
// Insert “Connect”.
7.2.2. OpenID Federation 1.0 Automatic Registraiton, the section title
OpenID Federation → OpenID Connect Federation
// Insert “Connect”.
7.2.2. OpenID Federation 1.0 Automatic Registration, the 1st paragraph
OpenID Federation → OpenID Connect Federation
// Insert “Connect”.
7.2.3. Decentralized Identifiers, the Request Object example, client_metadata
"subject_syntax_types_supported": "did:example”
→ "subject_syntax_types_supported": [ "did:example" ]
// The value should be a JSON array.
"id_token_signing_alg_values_supported": "ES256"
→ "id_token_signed_response_alg": "ES256"
// Change "id_token_signing_alg_values_supported"
to "id_token_signed_response_alg"
(cf. OpenID.Registration, 2. Client Metadata).
7.2.3. Decentralized Identifiers, the Request Object example, nonce
nonce=n-0S6_WzA2Mj
→ "nonce": "n-0S6_WzA2Mj"
// Make the line a valid JSON key-value pair.
7.3. Relying Party Client Metadata parameter, the Authorization Request example, client_metadata
id_token_signing_alg_values_supported%22%3A%5B%22RS256%22%5D%7D
→ id_token_signed_response_alg%22%3A%22RS256%22%7D
// Change "id_token_signing_alg_values_supported"
to "id_token_signed_response_alg"
(cf. OpenID.Registration, 2. Client Metadata), %5B%22RS256%22%5D
([“RS256”]) to %22RS256%22
(“RS256”).
7.4. Relying Party Metadata Error Response, the 1st paragraph
When Self-Issued OP receives a pre-registered → When the Self-Issued OP receives a pre-registered
// Insert “the”.
client_id
of a Section 7.1 → client_id
of Section 7.1
// Remove “a”.
parameters of a Section 7.2 → parameters of Section 7.2
// Remove “a”.
also present, Self-Issued OP → also present, the Self-Issued OP
// Insert “the”.
When Self-Issued OP receives a client_id
→ When the Self-Issued OP receives a client_id
// Insert “the”.
client_id
of a Section 7.2 → client_id
of Section 7.2
// Remove “a”.
it does not not return an error → it does not return an error
// Remove “not”.
7.4. Relying Party Metadata Error Response, the 3rd paragraph
Self-Issued OP might be seeing → the Self-Issued OP might be seeing
// Insert “the”.
where Self-Issued OP assigns → where the Self-Issued OP assigns
// Insert “the”.
after receiving RP’s metadata → after receiving the RP’s metadata
// Insert “the”.
7.5. Relying Party Metadata Values, subject_syntax_types_supported
JWK Thumbprint, valid value is → JWK Thumbprint, a valid value is
// Insert “a”.
It seems that some client_id
occurrences should be replaced with “client ID”. The expression of client_id
gives an impression that it is a parameter name. In some contexts, it is not appropriate. For example, in the context of client_secret_post
, client_secret_jwt
and private_key_jwt
client authentication methods, a client ID does not appear as the value of the client_id
parameter.
Comments (4)
-
reporter -
Is
Client identifier
more common thanClient ID
? -
- changed status to open
-
- changed status to resolved
PR merged
- Log in to comment