[Openid-specs-mobile-profile] MODRNA WG Call on Nov 2nd 2016 preliminary notes

Sun Nov 13 09:32:19 UTC 2016

Hi Gonzalo,

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.

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

-          Section 3

o   “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.”

-          Section 4

o   You should describe why this endpoint is not called Backend _Authentication_ Endpoint

o   New paragraph for “Communication with …”?

-          Section 5

o   client_notification_endpoint is mandatory for clients registered to receive callbacks

o   login_hint_token

o   OPTIONAL. As defined in OpenID Connect MODRNA Authentication Profile 1.0.

o   context – the MODRNA profile does not define a context parameter. I think you intended to include the parameter “binding_message”?

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.

-          Section 6

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

-          Section 12

o   How is the OP supposed to respond in case of an unknown or expired auth_req_id?

-          Section 13

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

o   “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.

o   “the authorization server returns an error response” -> “the authorization server _sends_ an error _message_”.

o   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).

o   Example: There is no need for a grant type, since this endpoint is designed for SIBA only

-          Section 15

o   What’s supposed to be described in this section beyond section 12 or 14?

-          Please add security and privacy considerations sections.

best regards,
Torsten.

Von: GONZALO FERNANDEZ RODRIGUEZ [mailto:gonzalo.fernandezrodriguez at telefonica.com]
Gesendet: Dienstag, 8. November 2016 15:02
An: philippe.clement at orange.com; Lodderstedt, Torsten; openid-specs-mobile-profile at lists.openid.net
Betreff: Re: [Openid-specs-mobile-profile] MODRNA WG Call on Nov 2nd 2016 preliminary notes

Hi guys,

Find below the link of the last version uploaded in the bitbucket with the requested changes in the Paris Workshop.

https://bitbucket.org/openid/mobile/src/c9c8669a143de215c1f2a6eedd8f743e7e229917/draft-mobile-client-initiated-backchannel-authentication-01.xml?at=default&fileviewer=file-view-default

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.

Best,
Gonza.

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

Dear all,

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.

Participants:
Axxel, Torsten, Siva, John, Nicolas,

Agenda:
·         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
Server authentication
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.

User Questionning
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.

account migration
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.

Next workshop
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.
Ort: https://global.gotomeeting.com/join/927253461

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.

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20161113/bde473a9/attachment-0001.html>