[Openid-specs-mobile-profile] CIBA comments

charles.marais at orange.com charles.marais at orange.com
Wed Nov 30 11:45:06 UTC 2016


Hi All,

To extend James comments, some additional comments :

Concerning the Use Cases,

A call center agent wants to authenticate a caller.

A major difference between CIBA and OpenID Connect Core flows is that 
potentially, there is no consumption device (for the SP) in that case. 
In this specific case, there is an additional requirement : the SP need 
to previously know the couple (sub/iss) for the user to authenticate... 
otherwise, in case of a new user, the federation with an existing 
account is not possible (because no user agent available). This points 
out the question of the first authentication of a specific user on that 
SP or reformulated : "How the SP discover/learn, the couple sub/iss for 
a specific user ?".

A bank wants to authenticate a customer.

What is the difference between this one and the first one ?

BR,

Charles.

Le 30/11/2016 à 07:42, Manger, James a écrit :
>
> 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 3^rd paragraph 
> to the first, deleting the poorer duplicates in the 1^st 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
>
>
>
> _______________________________________________
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile

-- 

*MARAIS Charles *
*Orange Labs Lannion*
Tel : +33 (0)2 96 07 24 18
charles.marais at orange.com <mailto:charles.marais at orange.com>
Orange Labs Lannion
2, avenue Pierre Marzin
22307 LANNION Cedex - France



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20161130/2b94675b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: orange_logo.gif
Type: image/gif
Size: 1264 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20161130/2b94675b/attachment-0001.gif>


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