[Openid-specs-mobile-profile] UQ error_code

nicolas.aillery at orange.com nicolas.aillery at orange.com
Wed Nov 23 14:24:47 UTC 2016


Hello Axel,

   Now I understand your point and I agree.
   It will be in draft v8,

Regards,

Nicolas

De : Axel.Nennker at telekom.de [mailto:Axel.Nennker at telekom.de]
Envoyé : mercredi 23 novembre 2016 10:18
À : AILLERY Nicolas IMT/OLPS
Cc : openid-specs-mobile-profile at lists.openid.net; MARAIS Charles IMT/OLPS; CLEMENT Philippe IMT TECHNO; VASSELET Mickaël IMT/OLN
Objet : UQ error_code

Hi Nicolas,

Thanks for the update.

I think it is best to continue the discussion of single topics in single emails. So here it goes.

Regarding error_code:

OAuth2 says in https://tools.ietf.org/html/rfc6749#section-5.2 e.g.:
HTTP/1.1 400 Bad Request
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "error":"invalid_request"
     }

UQ says 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
In section Errors:
{
        "error_code":"unknown_user",
        "error_description":"The user is unknown",
        "error_uri":"https://server.example.com/errors/unknown_user"
}

Why is UQ using "error_code" while OAuth2 uses "error" for the same value?
I agree with you - I think this is what you intended - that using "error_code" for the error code is better than using "error" for the error code.
But OAuth2 uses "error" for the error_code and specs deriving from OAuth2 should not change the field names.

MODRNA authentication https://bitbucket.org/openid/mobile/raw/default/draft-mobile-authentication-01.txt does not mention error structures at all. Maybe this is the way to go for UQ too - just list the possible error code (section 5.1) and drop the text re-explaining the JSON structure...

Sorry I was not clear in my review remarks



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


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