[Openid-specs-mobile-profile] CIBA comments

Axel.Nennker at telekom.de Axel.Nennker at telekom.de
Wed Nov 30 15:48:43 UTC 2016


Added some text to the Security Considerations section.
https://bitbucket.org/openid/mobile/commits/3f7edd3615ece674624ded87bc676e8c7cdc9d64

As per:
“14.   [7] Mention the risk to an OP of accepting arbitrary URIs for the client notification endpoint that it will later call. At least need to check it doesn’t point “inside” the OP’s network.”

//Axel

From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of Manger, James
Sent: Wednesday, November 30, 2016 7:42 AM
To: openid-specs-mobile-profile at lists.openid.net
Subject: [Openid-specs-mobile-profile] CIBA comments


Comment on OpenID Connect MODRNA Client initiated Backchannel Authentication Flow 1.0 <draft-mobile-client-initiated-backchannel-authentication-01>:



1.       [4.1] Client authentication to the CIBA endpoint is as per the token endpoint (eg with client creds), not as per an RS such as the UserInfo endpoint (eg with an access token). Good or Bad? I’m not certain.

2.       The spec doesn’t indicate how the CIBA endpoint can be discovered from OP metadata.



Mainly editorial:

1.       [Abstract] The abstract is too long with too much background and the intro too short. Swap them over. The abstract would be better as 1 paragraph on what CIBA delivers, while the intro can explain the relationship of other OpenID Connect flows.

2.       [intro] CIBA isn’t “an authentication flow of the [OIDC] Core 1.0 specification”. Perhaps describe it as an extension of OIDC.

3.       [3.1] specifiy → specify

4.       [3.1] Move the “registration at the OP” sentence from 3rd paragraph to the first, deleting the poorer duplicates in the 1st para.

5.       [3.2] The bank example doesn’t have enough (any) context. How about: “A bank teller wants to authenticate a customer in a bank branch” - so it is using CIBA for auth in a face-to-face scenario.

6.       [4.1] Don’t say a CIBA request is an OAuth 2.0 authz request, because it is different (it doesn’t redirect the user, and uses JSON not x-www-form-urlencoded). Say it uses some of the same parameters as an OAuth 2.0 (or OIDC) auth request.

7.       [4.1] “scope” parameter: put the “openid” scope value in quotes.

8.       [4.1] Add a blank line between HTTP headers and the body

9.       [4.2] Fix grammar around “and is not expired”

10.   [4.3] Should the min polling interval be expressed in milliseconds, instead of seconds which is almost too coarse

11.   [5] Don’t start by saying “once the end-user is authenticated”. Need some words about that being done, eg "The OP authenticates the user identified by the client. How this occurs is up to the OP, and is out-of-scope of this specification."; might need to mention acr_values.

12.   [6.1] The example’s body syntax is wrong (strange mix of part JSON, part x-www-form-urlencoded)

13.   [4.3, 6.2] Drop the Pragma headers. I don’t think the Cache-Control headers help either as POSTs are not cacheable by default anyway.

14.   [7] Mention the risk to an OP of accepting arbitrary URIs for the client notification endpoint that it will later call. At least need to check it doesn’t point “inside” the OP’s network.

15.   [6.3.2] OAuth 2.0 uses “access_token” (& “token_type”) to deliver a bearer token that the other party then uses. Might be better to use the same names, instead of using “client_req_id” to deliver a bearer token.

16.   [heading] The spec is dated “Aug 18, 2016”; should update that with each commit.



--

James Manger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20161130/74807d93/attachment.html>


More information about the Openid-specs-mobile-profile mailing list