[Openid-specs-mobile-profile] Request Authorization

Wed Nov 23 15:46:20 UTC 2016

Hi Axel,

using the client credentials on any other than the token endpoint requires the authorization server/OP to share this credentials among endpoints. This limits implementation/deployment options and we should have good reasons for doing so.

best regards,
Torsten.

Von: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] Im Auftrag von Nennker, Axel
Gesendet: Mittwoch, 23. November 2016 16:09
An: nicolas.aillery at orange.com
Cc: openid-specs-mobile-profile at lists.openid.net
Betreff: Re: [Openid-specs-mobile-profile] Request Authorization

The point I haven't thought of up until now in your answer below is that the Client can obtain an access token using its client credentials...
This explains too why UQ distinguishes between access tokens which are related to the user and those which are not.

What is the advantage of the client-credentials-based access token compared to using the client credentials in the UQ request?
This is a server to server connection so it should be reasonable secure to just use the client credentials.

If there are no compelling advantages I suggest to just requiring that the UQ request is authorized without restricting AZ and Client to Access Tokens. But spelling the two variants out in the specification might help implementers.

What do you think?

Axel

From: nicolas.aillery at orange.com<mailto:nicolas.aillery at orange.com> [mailto:nicolas.aillery at orange.com]
Sent: Wednesday, November 23, 2016 3:23 PM
To: Nennker, Axel
Cc: gonzalo.fernandezrodriguez at telefonica.com<mailto:gonzalo.fernandezrodriguez at telefonica.com>; openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>; MARAIS Charles IMT/OLPS; VASSELET Mickaël IMT/OLN; CLEMENT Philippe IMT TECHNO
Subject: RE: Request Authorization

Hello Axel,

   Here are my responses,

Regards,

Nicolas

De : Axel.Nennker at telekom.de<mailto:Axel.Nennker at telekom.de> [mailto:Axel.Nennker at telekom.de]
Envoyé : mercredi 23 novembre 2016 12:24
À : AILLERY Nicolas IMT/OLPS; 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>
Objet : Request Authorization

UQ and CIBA differ on how the request is authorized.

CIBA Section 4.2 refers to OpenID.Core section 9 for authorization:
https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication

https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication-01.xml?at=default#rfc.section.4.2

UQ relies on Access Tokens without specifying how they are optained:
https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-user-questioning-api.xml#rfc.section.4.1.2.1

UQ has to send the user at least once per the usual redirect dance to the AZ to obtain an access token for the AZ's UQ endpoint, right?
[NAY] UQ is an OAuth protected API (i.e. an Oauth Resource server). To use UQ, the Client must have a valid access_token obtained either by an OAuth AS or an OIDC AS. On the other hand, CIBA is an API that enables to get an access_token.
In prose: Dear user, do you allow Client to ask you questions in the future? Yes, No
[NAY] For UQ, the access_token can have been obtained thanks to a Oauth Client Credential flow, with no user interaction.
For that we would not need a new protocol, right? So the better question is:
Dear user, do you allow Client to spontaneously ask you questions in the future on your authentication device/mobile phone?
In this generality user will most likely decline, I guess.
Going through the UQ use cases https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-user-questioning-api.xml#rfc.section.1.5 the access token consent questions would be:

1)      Do you want Bank to get your consent when you buy something somewhere?

2)      Do you want Bank to get your consent to add payees to your account?

3)      Do you allow Food-Market to get your consent when an order needs to be changed?

4)      Do you allow Ticketshop to get your confirmation when you seem to buy tickets?

5)      Do you allow Airline to make sure you are aware of flight changes?

6)      Do you allow SurveyCompany to ask you questions on brands and products?

The Client has an Access Token that allows it to use the UQ endpoint to actually ask the questions.

My question regarding UQ: Why is the spec silent on where the question is asked? Should there be something like a questioning device?
[NAY] I don't get your point. If the user is prompted to consent the usage of the UQ API (i.e. scope=question) by a Client. The consent is a generic consent with no information on the future AMR that could be used. Once again, the user consent is not mandatory (e.g. Client Cred Flow).

My question regarding CIBA: Is OpenID.Core section 9 the right way for CIBA or should CIBA use Access Tokens as well or should CIBA just say the request needs to be authorized and whether this uses Client Credentials or Access Tokens is between Client and AZ.
[NAY] In my understanding, CIBA is an API of the OIDC AS. CIBA delivers the id_token and optionaly the access_token.

Cheers
Axel

From: nicolas.aillery at orange.com<mailto:nicolas.aillery at orange.com> [mailto:nicolas.aillery at orange.com]
Sent: Tuesday, November 22, 2016 6:58 PM
To: Nennker, Axel
Cc: openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>; Lodderstedt, Torsten; MARAIS Charles IMT/OLPS; CLEMENT Philippe IMT TECHNO; VASSELET Mickaël IMT/OLN
Subject: RE: User Questioning RE: [Openid-specs-mobile-profile] minutes of MODRNA WG Call Nov 16th 2016

Hello Axel,

   Thank you for your review.
   Please find my comments in your remarks,

Regards,

Nicolas

De : Axel.Nennker at telekom.de<mailto:Axel.Nennker at telekom.de> [mailto:Axel.Nennker at telekom.de]
Envoyé : jeudi 17 novembre 2016 13:25
À : AILLERY Nicolas IMT/OLPS; MARAIS Charles IMT/OLPS
Cc : 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>
Objet : User Questioning RE: [Openid-specs-mobile-profile] minutes of MODRNA WG Call Nov 16th 2016

Hi Nicolas, hi Charles,

I reviewed the UQ draft and here are my first remarks:

-                          Please consider whether the word "FORBIDDEN" can be replaced by "MUST NOT"
e.g. in 4.1.1 I suggest to reverse the order and rephrase to avoid FORBIDDEN:
"MANDATORY if the Access Token is not tied with an End-User. MUST NOT be present if the Access Token is tied with an End-User,"

-                          [NAY] OK, draft modified

Regarding 4.1.1 User Questioning Request

-                          "AUTHORIZATION" the paragraph seems to exclude the possibility to use client_id/client_secret and BASIC auth, right? Or does use of client_id/client_secret constitute the case "not tied to the user" while an access token constitutes the case "tied to the user"?

-                          [NAY] UQ API is defined as an OAuth 2.0 API, requiring an access_token. Client_id/client_secret or HTTP Basic Auth are excluded.

-                          user_id "tied to the user" should be explained. I suggest adding text to the paragraph about "AUTHORIZATION" and the access token.

-                          [NAY] OK, draft modified (4.1.2.1)

-                          user_id versus sub
Why not use sub always instead of user_id? "sub" has the advantage that it is not widely known because it was assigned by the OP to the user for this Client. "sub" is never reassigned while a user_id might not be eternally assigned to the user. Yes, User_id_type can be sub but sub is harder to misuse by a rogue Client.

-                          4.1.2.2 says "user_id as a reachability means": Should the OP be free to decide how to contact the user on which device? Or does the Client decide on that by requesting a certain channel/device to be used?

-                          I suggest to add "sub" as MANDATORY to the UQ request.

-                          [NAY] 'sub' is an option, but other types  (e.g MSISDN) must be allowed for RP that don't use (or don't known) the sub. The OP must find a mean to reach the user. If the user_id is a reachability identifier, it should be used.

-                          "wished_acr" Why not use "acr_values" from OpenID.Core?

-                          [NAY] there is more semantic in 'wished'

-                          "wished_amr" like acr_values?: amr_values?

-                          [NAY] there is more semantic in 'wished'

-                          "wished_*" is the order of the values important? There is no text regarding the order.

-                          [NAY] OK, draft modified (order SHOULD be considered by OP)

Regarding 4.1.2.2 Processing user_id

-                          I would not conflate user_id as sub and user_id as reachability means!

-                          [NAY] a user_id is just a user identifier. It can be of different types. Some types can be directly used to reach the user (e.g. MSISDN), other cannot (e.g. sub). The way the user is reach is up to the OP. The user_id is a mean for the RP to designate the User. If the access_token is associated with a user, the user_id is useless.

-        Wondering about the wording here:
"If the user_id is present in both the User Questioning Request and the Access Token, an error is raised."
If the access token is "SlAV32hkKG" does this cover the "present in" wording?
How about: "If the user_id is present but the Access Token is bound to a user then the user_id and the sub associated with the Access Token MUST be identical". (Not replacing user_id by sub in this for now. I think the parameter "user_id" should be replaced by "sub" and a reachability parameter)

-                          [NAY] If the identifiers are identical, one is useless. The spec states that the Client has to choose to identify the user thanks to either the AT or the user_id, but not both.

Regarding 4.1.3 Successful Response

-                          I am not sure whether transporting the polling URL in the Location header.

-                          [NAY] OK, draft modified (JSON is used)

-                          I am not sure whether the polling location should be dynamic.
Being dynamic has advantages because it can be dynamic based on client and/or question and/or server load etc...

-                          Being dynamic has the disadvantage that the Client has to decide at polling time whether some policy might forbid it to talk to the polling endpoint.

-                          [NAY] It a pending discussion

The example does not contain a JSON structure! Should this read like this:
HTTP/1.1 200 OK
{  "Location": "https://server.example.com/questions_polling/984dcc7d3d4d4b0f9f8022e344f9",
   "Question_id": "984dcc7d3d4d4b0f9f8022e344f9"
}

-                          [NAY] OK, draft modified (JSON is used)

Regarding 4.1.4 Error Response:

Why is this different to OAuth2 Section 5.2 Error Response?

https://tools.ietf.org/html/rfc6749#page-45

-                          [NAY] It detailed in §5 that uses the same structure as OAuth. The way the structure (error_info) is transmitted depends on the endpoint (400 or POST)

Regarding 4.3.2 Error Response

Like 4.1.4 make this look more like OAuth2 Section 5.2 Error Response?

-                          [NAY] It detailed in §5 that uses the same structure as OAuth. The way the structure (error_info) is transmitted depends on the endpoint (400 or POST)

Regarding 6.1 Implementation of questioning methods

-                          Change headline to headline style (Capitalized Words)

-                          [NAY] I did not understand the comment

-                          Add supported AMR and ACR etc to discovery.
"To prevent these errors, it can inform the Clients of its limitation and limit the possible questions or statements."

-                          [NAY] OK, draft modified (amr_list, acr_list)

-                          [NAY] Would you add 'displayed_question_length', 'displayed_statement_length', 'displayed_statement_number' in discovery ?

Have to go now - So stopped reviewing for now before section 7 Security Considerations.

Cheers

Axel

From: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] On Behalf Of philippe.clement at orange.com<mailto:philippe.clement at orange.com>

Sent: Wednesday, November 16, 2016 6:07 PM

To: Lodderstedt, Torsten; openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>

Subject: [Openid-specs-mobile-profile] minutes of MODRNA WG Call Nov 16th 2016

Please find below the preliminary notes of the call.

Should you detect any error or misunderstanding, please let me know.

Participants : John, Axel, Bjorn, Charles, Torsten, Joerg

Agenda :

* Review UQ specs

* Review SIBA specs

* Next workshop

Discussion :

User Questionning

A new draft has been released by Orange, following questions/remarks from Torsten

Axel and Bjorn volunteer to review the UQ draft specs.

Torsten to send a reminder to the list for reviewing, before entering the implementers draft process.

A proposal is made for OIF to present a status update of UQ work at the next PET GSMA meeting (end of November). Orange will help to draft this presentation. PET chairman to be contacted for insertion into the agenda.

SIBA

Questions about the context parameter that shows up in the specs. Discussions in Paris had only stated a use for the binding message to interlock devices. Recommendation from the call is to remove this parameter.

Charles volunteers to post comments on SIBA specs, other comments are awaited from the list.

Mentionning the Use Cases in SIBA specs is requested to understand some choices in the specs, and will avoid any duplication with User Questionning.

Idea of merging some parts of SIBA and UQ are set on the table, but draft specs should be more mature.

Next workshop

For information, John should be in London January 18 and 19th, to take into consideration.

AOB: push style

Discussion occurs on OAuth list regarding push style for the device flow.

Some arguments are presented to balance push vs pull approach, for UQ.

* Complexity for the RP to implement 2 solutions

* Resource optimization from an OP side

* Number of requests per second

* Delay for the user to answer the question (seconds, minutes ?)

Discussion to be continued on the list through the specs

Best regards,

Philippe

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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/20161123/b1b2b9af/attachment-0001.html>