[Openid-specs-mobile-profile] Client initiated Backchannel Authentication diagrams
Axel.Nennker at telekom.de
Axel.Nennker at telekom.de
Mon Nov 21 15:07:23 UTC 2016
Hi Gonza, hi Walter,
I added two diagrams to the CIBA spec.
Currently there is no representation of authentication and consumption device in them. Should those be added?
From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of GONZALO FERNANDEZ RODRIGUEZ
Sent: Tuesday, November 15, 2016 6:49 PM
To: Lodderstedt, Torsten
Cc: openid-specs-mobile-profile at lists.openid.net
Subject: Re: [Openid-specs-mobile-profile] MODRNA WG Call on Nov 2nd 2016 preliminary notes
First of all many thanks for your detailed review, find below my answers in line….
I have just uploaded almost all the changes.
From: "Torsten.Lodderstedt at telekom.de<mailto:Torsten.Lodderstedt at telekom.de>" <Torsten.Lodderstedt at telekom.de<mailto:Torsten.Lodderstedt at telekom.de>>
Date: domingo, 13 de noviembre de 2016, 10:32
To: Gonzalo Fernandez Rodriguez <gonzalo.fernandezrodriguez at telefonica.com<mailto:gonzalo.fernandezrodriguez at telefonica.com>>
Cc: "openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>" <openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>>
Subject: AW: [Openid-specs-mobile-profile] MODRNA WG Call on Nov 2nd 2016 preliminary notes
thanks for updating the draft.
Here are my comments:
- Abstract: I would suggest to add text, which explains is intended to work in conjunction with out-of band authentication mechanisms. Traditional username/password authentication is not desired and won’t work. This is important since this flow won’t cause any user credentials to go through the RP.
[gfr] —> OK, I changed the text.
- Structure: I suggest you to employ sub-sections in order to give the document a simpler to understand structure. I think sections 5-8 should be sub-sections of 4. 9 belongs to a potential section “Processing of the authentication transaction”, as it gives considerations for the AS regarding user consent. I think there are more pre-requisites and considerations, e.g. authentication is performed OOB. 10-15 seems to belong to the overall “how to obtain the transaction result” topic.
[gfr] —> That potential section (9) now (5) after including 5-8 sections as subsection of 4, what is supposed to have additionaly to the current section “Authorization Server Obtains End-user Consent/Authorization” or it is only a change of the title?
[gfr] —> OK.
- Section 3
“It reuses most of the request parameters in the Authentication Request, at the same time, it specifies some new parameters as well as a new authentication endpoint.” I would suggest to gives this paragraph a more specific description of the rational of which parameters are used und which are not. Probably like this: “It introduces a new endpoint used to initiate authentication transactions using a backchannel requests. This new endpoint utilizes existing Authentication Requests and defines new parameter as appropriate. For example, it re-uses the scope parameter but it omits nonce, state and redirect_uri, which are need to perform and secure authentication transactions on the front channel.”
[gfr] —> OK
- Section 4
You should describe why this endpoint is not called Backend _Authentication_ Endpoint
New paragraph for “Communication with …”?
[gfr] —> OK, I changed the name of the endpoint by Backend "Authentication Endpoint”
- Section 5
client_notification_endpoint is mandatory for clients registered to receive callbacks
OPTIONAL. As defined in OpenID Connect MODRNA Authentication Profile 1.0.
[gfr] —> I don’t understand what happens with “login_hint_token”
o context – the MODRNA profile does not define a context parameter. I think you intended to include the parameter “binding_message”?
[gfr] —> It is a new parameter, it was requested to use this parameter instead of using binding_message that has a clear intention to interlock both devices (consumption and authentication)
o I miss the parameter to send the access token from the RP to the OP, the OP is supposed to use for authorizing the callback to the notification endpoint.
[gfr] —> What I understood was to use the client_req_id value as token to authenticate the callback request. Do you mean it is necessary to send another paremeter indicating the “bearer” type?
- Section 6
How is the OP supposed to react in case it cannot find a user account using login_hint etc? I would assume it responds with an error.
[gfr]—> I agree, I suposse that we have different use cases:
- login_hint does not exist
- id_token_hint —> does not exist or it is expired (maybe the same if it is remove from the system when expired)
- login_hint_token —> does not exist or it is expired (maybe the same if it is remove from the system when expired)
Do you think is it necessary to create a new error to identify that the provided hint like:
The login_hint, id_token_hint or login_hint_token) are not found
- Section 12
How is the OP supposed to respond in case of an unknown or expired auth_req_id?
[gfr] —> Maybe a 404 Not found? What do you think?
First sentence “When the authentication request includes a "client_notification_endpoint …” – I think it should read like this “When the client is registered for client notification …” or similar.
“If the user is well authenticated, the Authorization Server returns a successful response that includes an ID Token and an Access Token.” Don’t forget the refresh token.
“the authorization server returns an error response” -> “the authorization server _sends_ an error _message_”.
I think it makes sense to give a definition of the client notification endpoint in the same way as for the “Backchannel Authorization Endpoint” – this description should include TLS considerations, parameters and explain the way this endpoint is protected from abuse (RP-generated access token from OP to RP).
Example: There is no need for a grant type, since this endpoint is designed for SIBA only
[gfr] —> OK, I agreed, changes have been done.
- Section 15
What’s supposed to be described in this section beyond section 12 or 14?
Please add security and privacy considerations sections.
[gfr] —> OK, added. Maybe here people can give me feedback about some other points they think are necessary to bear in mind.
Von: GONZALO FERNANDEZ RODRIGUEZ [mailto:gonzalo.fernandezrodriguez at telefonica.com]
Gesendet: Dienstag, 8. November 2016 15:02
An: philippe.clement at orange.com<mailto:philippe.clement at orange.com>; Lodderstedt, Torsten; openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Betreff: Re: [Openid-specs-mobile-profile] MODRNA WG Call on Nov 2nd 2016 preliminary notes
Find below the link of the last version uploaded in the bitbucket with the requested changes in the Paris Workshop.
I have a doubt in one of the points about how to authenticate the callback, as far as I remember we agreed to generate a bearer token in the RP that would be sent in the authentication request and it would be used to authenticate the callback POST request when using the client_notification_endpoint. Please let me know if you agree.
From: Openid-specs-mobile-profile <openid-specs-mobile-profile-bounces at lists.openid.net<mailto:openid-specs-mobile-profile-bounces at lists.openid.net>> on behalf of "philippe.clement at orange.com<mailto:philippe.clement at orange.com>" <philippe.clement at orange.com<mailto:philippe.clement at orange.com>>
Date: miércoles, 2 de noviembre de 2016, 17:34
To: "Torsten.Lodderstedt at telekom.de<mailto:Torsten.Lodderstedt at telekom.de>" <Torsten.Lodderstedt at telekom.de<mailto:Torsten.Lodderstedt at telekom.de>>, "openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>" <openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>>
Subject: [Openid-specs-mobile-profile] MODRNA WG Call on Nov 2nd 2016 preliminary notes
Please find below the preliminary notes of our call this Wednesday Nov 2nd, 2016.
In case of any error or misunderstanding, please let me know.
Axxel, Torsten, Siva, John, Nicolas,
· OIDC workshop
· Status of current drafts
· Next workshop
OIDC Workshop before IIW
John: update of the presentation around MODRNA, presented at OIDF workshop
Well received, with Interest.
Status of current drafts
Following a side conversation with Gonzalo, Torsten made a quick read of the draft.
Doesn’t seem to cover all remarks that was discussed in Paris.
To all: give a read to the draft document.
One people (Torsten) has made a feedback to UQ.
A new draft (version 4) is ready to be pushed to github, including security remarks.
Nicolas to push it once the concern regarding links to URLs is fixed.
waiting for an update from James.
Torsten: AM is a complex task to be stabilized and get mature. Complex on the security aspects.
Torsten to check with James the status of the draft, and to evaluate impact of security concerns.
· Feddback required from the group on the 3 drafts before the next call (Nov 16th) to make actual drafts turn into implementer’s draft. Remarks regarding security aspects are welcome too.
Has a group member the intention to host the next one ? Globalsign had mentioned this possibility in Paris.
Next workshop could happen in feb/march 2017
Zeit: Mittwoch, 2. November 2016 16:00-17:00 (UTC+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm, Wien.
Hinweis: Die oben angegebene Abweichung von GMT berücksichtigt keine Anpassungen für Sommerzeit.
<< Fichier: ATT00001.txt >>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-mobile-profile