[Openid-specs-ab] Issue #1833: SIOP: typos in draft 12, from Abstract to Section 7 (openid/connect)

Sun Feb 26 18:11:48 UTC 2023

New issue 1833: SIOP: typos in draft 12, from Abstract to Section 7
https://bitbucket.org/openid/connect/issues/1833/siop-typos-in-draft-12-from-abstract-to

Takahiko Kawasaki:

### 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](https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata)\).

### 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` → `id_token_signed_response_alg`

// Change `"id_token_signing_alg_values_supported"` to `"id_token_signed_response_alg"` \(cf. OpenID.Registration, [2. Client Metadata](https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata)\).

### 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.