CIBA: Typos in 2018-Dec-12 draft

Issue #129 resolved
Takahiko Kawasaki
created an issue

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.

Comments (7)

  1. Brian Campbell

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

    SP is sometimes used with the same meaning as RP because of the roles in SAML 2. But this doc should be (somewhat) consistent so I'll replace that SP with RP.

  2. Brian Campbell

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

    I'm not sure about the whole sentence that phone number wording appears in. But it's been there for a long time and I'm reluctant to change it much at this point. But I can make "phone numbers" more generic to something like "identifiers".

  3. Log in to comment