SIOP: typos in draft 12, from Abstract to Section 7

Issue #1833 resolved
Takahiko Kawasaki created an issue

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%7Did_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)

  1. Log in to comment