[Openid-specs-mobile-profile] Issue #129: CIBA: Typos in 2018-Dev-12 draft (openid/mobile)

[Takahiko Kawasaki]

New issue 129: CIBA: Typos in 2018-Dev-12 draft
https://bitbucket.org/openid/mobile/issues/129/ciba-typos-in-2018-dev-12-draft

Takahiko Kawasaki:

**1. Introduction, the last paragraph**

```
out-band mechanisms ->
out-of-band mechanisms
```

**3. Overview, the 1st paragraph**

```
out-band mechanisms ->
out-of-band mechanisms
```

**3. Overview, 3.**

```
Ping or Push modes, this choice MUST ->
Ping or Push modes. This choice MUST
```

**4. Registration and Discovery Metadata, OpenID Provider Metadata, backchannel_token_delivery_modes_supported**

```
a JSON array ->
JSON array
```

```
the following values "poll", "ping" and "push" ->
the following values: "poll", "ping" and "push"
(unless the omission of ':' or other delimiter is intentional)
```

**4. Registration and Discovery Metadata, Client Metadata, backchannel_token_delivery_mode**

```
the following values "poll", "ping" and "push" ->
the following values: "poll", "ping" and "push"
(unless the omission of ':' or other delimiter is intentional)
```

**5. Poll, Ping and Push Modes, Poll Mode Diagram**

Remove a space after "(2) User interactions".
(other arrows don't have a space after strings)

**5. Poll, Ping and Push Modes, Ping Mode Diagram**

Replace the underscore after "(2) User interactions" with a hyphen.

**5. Poll, Ping and Push Modes, Push Mode Diagram**

Remove a space after "(2) User interactions" and "(3) CIBA Push Callback".
(other arrows in other diagrams don't have a space after strings)

**6. Examples of Use Cases**

```
A user wants to user ->
A user wants to use
```

```
smartphone to authorise ->
smartphone to authorize
```

**7.1. Authentication Request, the 1st paragraph**

```
MODRNA Client Initiated Backchannel Authentication ->
Client Initiated Backchannel Authentication
(unless MODRNA is placed there intentionally.)
```

**7.1. Authentication Request, scope**

```
Consitent with ->
Consistent with
```

**7.1. Authentication Request, example of an authentication request**

`&` should be added after `binding_message=W4SCT`.

**7.1.1. Signed Authentication Request, the paragraph after `jti`**

```
MUST NOT be be outside ->
MUST NOT be outside
```

**7.1.2. User Code, the 3rd paragraph**

```
where caller id is ->
where a caller ID is
```

**7.2 Authentication Request Validation, 1.**

```
It is RECOMMENDED that Clients do not send ->
It is RECOMMENDED that Clients not send
```

```
rather that public key cryptography is used ->
rather that public key cryptography be used
```

**7.3. Successful Authentication Request Acknowledgement**

```
example from an authentication response ->
example of an authentication response:
("of" and a semi-colon at the end)
```

**7.4. Authentication Request Acknowledgment Validation, the 2nd paragraph**

```
to use when polling the token endpoint in Poll mode ->
to use when making a token request in Poll and Ping modes
```

**9. Client Notification Endpoint, the 4th paragraph**

```
did not grant authorisation ->
did not grant authorization
```

**10.1. Token Request Using Backchannel Request Grant Type, the 5th paragraph**

```
as if it was registered to use the Poll mode ->
as if it had been registered to use the Poll mode
```

**10.1. Token Request Using Backchannel Request Grant Type, the 6th paragraph**

```
makes a "POST" request ->
makes an "HTTP POST" request
```

Some `HTTP POST` are enclosed with double quotation marks (like `"HTTP POST" request`) and the others are not (e.g. the 1st paragraph of 10.2.). It would be better to align to either of them.

**10.2. Ping Callback**

```
with HTTP 200 OK, any body ->
with HTTP 200 OK and any body
```

**10.3.1. Successful Token Delivery, the paragraph after the first example**

```
If the bearer token is not valid the Client ->
If the bearer token is not valid, the Client
```

**11. Token Error Response, the 1st paragraph**

```
constructs the error response ->
constructs an error response
```

**11. Token Error Response, access_denied**

```
The end user denied ->
The end-user denied
```

**12. Push Error Payload**

`error_uri` is not mentioned.

**12. Push Error Payload, access_denied**

```
The end user denied ->
The end-user denied
```

**13. Authentication Error Response, missing_user_code**

```
missing from request ->
missing from the request
```

**13. Authentication Error Response, access_denied**

```
The mechanism for such a decision to be made in outside the scope of ->
The mechanism for such a decision to be made is outside the scope of
```

**14. Pairwise Identifiers, the 3rd paragraph**

> Pre-arranged configurations between SP and OpenID Provider are always possible.

What is "SP"? It would be better to write the definition of "SP" somewhere.

**15. Security Considerations, the 1st paragraph**

```
The login hint token SHOULD ->
The login_hint_token SHOULD
```

**15. Security Considerations, the 1st paragraph**

> The signature allows the OP to authenticate and authorize the sender of the hint and prevent collecting of phone numbers by rogue Clients.

I'm not sure _"prevent collecting of phone numbers"_ is appropriate in the context of CIBA **Core** specification.

**16. Privacy Considerations, ID Token containing a pairwise identifier**

```
a CIBA flow can be initialised ->
a CIBA flow can be initialized
```

**17.1. OAuth Authorization Server Metadata Registration**

`backchannel_user_code_parameter_supported` is missing.

**17.2. OAuth Dynamic Client Registration Metadata Registration**

`backchannel_user_code_parameter` is missing.

**17.4. JSON Web Token Claims**

```
encoded as claims of a the request JWT ->
encoded as claims of the request JWT
```

**Appendix B. Notices**

> Copyright (c) 2015 The OpenID Foundation.

The year of the copyright should be updated properly.