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

Torsten.Lodderstedt at telekom.de Torsten.Lodderstedt at telekom.de
Wed Nov 16 01:16:56 UTC 2016


Hi Gonzalo,

see comments inline.

best regards,
Torsten.

Von: GONZALO FERNANDEZ RODRIGUEZ [mailto:gonzalo.fernandezrodriguez at telefonica.com]
Gesendet: Mittwoch, 16. November 2016 02:49
An: Lodderstedt, Torsten
Cc: openid-specs-mobile-profile at lists.openid.net
Betreff: Re: AW: [Openid-specs-mobile-profile] MODRNA WG Call on Nov 2nd 2016 preliminary notes

Hi Torsten,

First of all many thanks for your detailed review, find below my answers in line….

I have just uploaded almost all the changes.

Best,
Gonza.

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

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

As I stated, you should describe other assumptions and pre-requisites, such as the OP is supposed to send an authentication request to the authentication device OOB. And I would suggest to change the title because the OP does a lot except user consent gathering. I therefore suggested  “Processing of the authentication transaction”.

[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

login_hint_token

OPTIONAL. As defined in OpenID Connect MODRNA Authentication Profile 1.0.
[gfr] —> I don’t understand what happens with “login_hint_token”

Please ignore, seems to be an unintended text fragment (CnP you know J)


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)

Who requested this? I cannot remember any discussion in Paris or on the mailing list. As your draft states SIBA “Authentication Requests are made using the MODRNA profile.” So please stick to the respective parameters or discuss the need for other parameters in the WG BEFORE you add them to the spec.


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?

The idea is the client mints a dedicated access token (in the format and containing the data it desires) and sends it in an additional parameter (in UQ it is called client_notification_token).


-          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:
- hint_not_found
The login_hint, id_token_hint or login_hint_token) are not found

I think we need two error codes for unknown user id and token expired.


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

I would say 400 + new error code.


Section 13

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.

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

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/20161116/15eec6e0/attachment-0001.html>


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