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

Axel.Nennker at telekom.de Axel.Nennker at telekom.de
Thu Nov 17 12:25:11 UTC 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,"

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

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

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

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

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

-                          "wished_amr" like acr_values?: amr_values?

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


Regarding Processing user_id

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

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

Regarding 4.1.3 Successful Response

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

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

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"

Regarding 4.1.4 Error Response:

Why is this different to OAuth2 Section 5.2 Error Response?


Regarding 4.3.2 Error Response

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

Regarding 6.1 Implementation of questioning methods

-                          Change headline to headline style (Capitalized Words)

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

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



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

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

To: Lodderstedt, Torsten; 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.


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,



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/20161117/01e2f7e0/attachment-0001.html>

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