[Openid-specs-mobile-profile] UQ wished_*

Wed Nov 23 15:09:53 UTC 2016

Hi Nicolas,

I agree that a "wisched for" or "requested" acr/amr expresses better what the semantic is but the semantic of wished_acr and acr_values or OpenID.Core is the same, right? I would not rename the parameter in UQ and when acr_values stays the same then I think that wished_amr should be amr_values to stay in the same naming scheme.
The whole thing is a _request_ so I think that it is clear that the parameters acr_values and amr_values are requested/wished_for things.

Kind regards
Axel

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

From: 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; 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