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

Torsten Lodderstedt torsten at lodderstedt.net
Wed Nov 23 07:29:14 UTC 2016


Hi all,

just as an observation: I think the spec needs to distinguish addresses and user ids. 
To me it seems like everybody is getting confused by user ids used to "reach" the user. I think "address" to reach a user is the better term.

just my 2 cents.

best regards,
Torsten.

> Am 22.11.2016 um 18:58 schrieb <nicolas.aillery at orange.com> <nicolas.aillery at orange.com>:
> 
> 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] 
> Envoyé : jeudi 17 novembre 2016 13:25
> À : AILLERY Nicolas IMT/OLPS; MARAIS Charles IMT/OLPS
> Cc : Torsten.Lodderstedt at telekom.de; 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
> 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. 
>  
> 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.
> _______________________________________________
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20161123/dcba4d49/attachment-0001.html>


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