[Openid-specs-mobile-profile] CIBA comments

Wed Nov 30 13:42:08 UTC 2016

These two lines were mainly entered to demonstrate agreement that the use case section is needed.

The difference between the two might be that

1)      the call center agents trigger the CIBA request using the MSISDN they see on their telephone. Their Backend is then using client_id/client_secret to authenticate to the OP and CIBA delivers the id_token to the RP with further user claims.

2)      The Bank clerk might know some account number of their costumer which the bank backend translates into a iss/sub data (whatever) because there is an account number to iss/sub relationship that the bank has learned from another interaction of the customer with the Bank’s system. There might be an access token from that earlier interaction that the RP (Bank) uses to authentication the CIBA request.

Certainly the use cases need to be more than one line and I would be happy if you provide your own additional use cases for CIBA.
Please provide text.

//Axel

From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of charles.marais at orange.com
Sent: Wednesday, November 30, 2016 12:45 PM
To: openid-specs-mobile-profile at lists.openid.net; AILLERY Nicolas IMT-OLPS; VASSELET Mickael IMT-OLN; CLEMENT Philippe IMT TECHNO
Subject: Re: [Openid-specs-mobile-profile] CIBA comments

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

_______________________________________________

Openid-specs-mobile-profile mailing list

Openid-specs-mobile-profile at lists.openid.net<mailto:Openid-specs-mobile-profile at lists.openid.net>

http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile

--
[cid:image001.gif at 01D24B17.BFC0CBA0]

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/c126b76e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 1264 bytes
Desc: image001.gif
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20161130/c126b76e/attachment-0001.gif>