[Openid-specs-mobile-profile] [User Questioning API] Third draft

nicolas.aillery at orange.com nicolas.aillery at orange.com
Wed Oct 19 12:28:43 UTC 2016


Hello Torsten,

   Thanks for your review.
   I give my answers in your text.

Regards,

Nicolas

De : Torsten Lodderstedt [mailto:torsten at lodderstedt.net]
Envoyé : samedi 15 octobre 2016 12:31
À : AILLERY Nicolas IMT/OLPS; openid-specs-mobile-profile at lists.openid.net
Cc : VASSELET Mickaël IMT/OLN
Objet : Re: [Openid-specs-mobile-profile] [User Questioning API] Third draft

Hi Nicolas,

here are my comments.

First of all: this revision represents a major leap forward in terms of readability and simplicity! Thanks for putting much effort into restructuring (and I think rewritting) it.

Major findings:

- statement values: As far as I remember, the WG agreed in Paris to stick to fixed, pre-defined statement values. I think we discussed "Accept" & "Deny" + another value to represent the fact the user does not want or is unable to answer the question - could be "Abort" or "refuse". So there is no need to specify statement values in the UQ request and other places. We need a clear common understanding (and documentation) of the scope of this draft. What's you take on that?
[NAY]

·         If the user refuses to answer, there is an error 'user_refused_to_answer' as it would not be logical to return as a statement (in the User Statement Token) the fact that the user refused to give a statement.

·         I agree that, in a first version, we should stick to closed question with fixed answers. Using only the technical values 'accept' or 'deny' raises an issue as we consider that the OP is responsible of asking the question to the good user (and returning the user's statement) but the Client is the only entity (with the user) aware of the semantic. It's the reason why it so important to display the question as it was written by the Client (and to notify the Client of any change in the display). For the same reason, it's very important that the Client can chose the exact answers that will be displayed to the user. In this draft, the Client takes the full responsibility of the wording of both the question and the possible answers.

·         Moreover, limiting to 2 possible answers is uselessly limitative as it is very simple to implement on the API side (tested on Orange prototype) and can drive new business

·         If the Questioning Mechanism is too limited to handle more than 2 possible answers or the adhoc display of answer, the limitation can be handled easily on Client side ( you can ask any question as long as the answers are 'accept' or 'deny' ;) ).


- I'm struggeling to understand the way the user questioning response is supossed to work (section 6.1.2.): status code 201 implies a new resource had been created. I see how this could work for the pull mode, although I don't see the need. I don't understand how it works in conjunction with the push mode. In this case, all the client needs is the question_id in order to sucessfully match the respective transaction. The new resource is useless since it is never used.
[NAY] agreed

Wrt to the pull mode: the question_id should be contained in the resource URL, so no need to return it to the client as additional parameter. Moreover, I think the design could be simplified by using a static endpoint for obtaining the result, which takes the question_id as parameter. This endpoint should be discovered by the client using the openid-configuration.
[NAY] What is the 'openid-configuration' ?

My proposal is:
- the user questioning result returns the question_id (which works across the different modes) and HTTP status code 200.
- polling: the client discovers the User Questioning Polling Endpoint from the openid-configuration and sends the request as described in section 6.2.1 with the question_id as additional parameter.
- push: can stay "as is"
[NAY]

·         OK for 200 OK and question_id in both modes

·         In Pull mode, I would keep an optional 'PollingUri' that must be used as is when present and that may not include the question_id. It's our current implementation and make the client very simple to develop.

I know this is not RESTful, but it fits with the design principles of the rest of the protocol suite.

- The document misses a description of how an user id is determined based on the user_id parameter or the access token. I recommend to add it after section 3 and merge it with the text in section 6.1.1.1
[NAY] OK

 - I suggest to add a section about discovery, mainly to describe the new value "question" for "scopes_supported" claim and the additional UQ-specific endpoints (uq_endpoint, uq_polling_endpoint)
[NAY] OK
 - I recommend you to fill the security/privacy sections soon since those sections are a pre-requisite to move the draft forward
[NAY] OK
smaller findings:

section 1
- "Whether the End-User is currently using the Client or not is also out of scope of this specification." Meaning of this sentence is unclear to me.
[NAY] I should rewrite it like this: "The Client can use the endpoint defined in this specification whether the End-User is currently using the Client or not."
section 2
- figure: would it be possible to move the end user to the right-hand side of the OP? It confused me a bit when I followed to flow to go back into the direction of the client in oder to communicate to the user.
[NAY] Due to the limited width allowed for figures by the RFC template, it will be very difficult to do
2.2.1
1st bullet: "1. The Client needs to have a real-time interaction with an offline End-User." - "offline" sounds odd since the OP will interact with the user via an online connection
[NAY] proposition : "The Client needs to have a real-time interaction with an End-User that may not be currently using the Client."
2nd bullet: "2. The Client needs to have the End-User's statement on a given question."- In the sense of "question and answer cryptographically bound to validated user identity?"
[NAY] it's just about semantic here. The Client needs to question the user.
4th bullet: "4. The Client needs to have a non-repudiable proof of the End-User's statement. " - Does the current draft fulfill this requirement?
[NAY] Yes. In a first step, it's the OP that can not repudiate the User Statement Token. Later, we can imagine that the user device will sign the User Statement Token.
section 3
question_id - Which entity is supposed to create it?
[NAY] the OP
iss - Isn't this always the OP? If so, pls. state it.
[NAY] In this specification, only the OP can sign. In the future, the user's device should be allowed to do so.
Description of aud and sub seem to be copied from the OpenID Connect Core spec - can we just refer to the respective definition instead of c'n'p?
[NAY] OK
user_id/user_id_type: Those are the mirrored parameter values - I would suggest to add some text about the purpose of adding them to the statement.
[NAY] done
used_qcr/used_qmr: The description makes obvious we are talking about the ACR of the authentication used in the context of the questioning. So no need to introduce new terminology - I would suggest to use a term like used_acr or at best just acr and amr.
[NAY] not all AMR can be used for questioning. And, I guess not all QMR can be used for authentication. In our prototype, we used SMS_URL (SMS with a link to a web form): AMR=SMS_URL and QMR=SMS_URL would link to different forms.


"User Statement Tokens MUST be signed ...." - Which entity is supposed to sign it, which entity is supposed to decrypt it?
[NAY] Signed by the OP, verified by the Client. Encryption is optional.

Example statements: No quotation marks for JSON numbers
[NAY] done

section 4

I think formating of the text could be simplified and should be extended.

Here is my proposal:

"In order to use the User Questioning API, the Client MUST have the right to access the User Questioning API. The right for a Client to access the User Questioning API is the right to use the User Questioning API's scope. This scope value is "question".
If the the Client wants to be notified of the User Question Response (cf. Section 5.2), it MUST register its client_notification_endpoint. The client_notification_endpoint is a callback URL on the Client. If the client does not use the client notification, it MUST obtain the result by using the user questioning polling endpoint. Both mechanisms are mutual exclusive, i.e. a particular client_id can only be used with one of these mechanisms. "
[NAY] Done, but splitted in two paragraphs.

section 5.2

on the client_notification_endpoint / to the client_notification_endpoint
[NAY] done

section 6.1

Intro should state something about use of HTTPS/TLS
[NAY] done
section 6.1.1.

heading "Request with User Questioning Request" -> "User Questioning Request"
[NAY] done

"The HTTP POST request contains the following header" -> "The HTTP POST request MUST contain the following header"
[NAY] done

request attribute definitions:
client_notification_token: "MANDATORY if the Client uses the Pushed-To-Client Flow described in Section 5.2. IGNORED otherwise." - I would suggest any deviation from the spec should cause an error - ignoring such mistakes may lead to undiscovered errors == problems
[NAY] OK
user_id_type: value range?
[NAY] I added a reference to §6.1.1.1
section 6.1.3

Which purpose serves the additional JSON member "error_info"? I would suggest to stick to the definition of the error response given in RFC 6749 (https://tools.ietf.org/html/rfc6749#section-5.2?)
[NAY] agreed

section 6.2.3

question_id is contained in the request URL, the response payload and the statement. Is there any validation logic the client is supposed to perform to ensure the consistency?
[NAY] I added a 'SHOULD check equality'


best regards,
Torsten.
Am 05.10.2016 um 16:05 schrieb nicolas.aillery at orange.com<mailto:nicolas.aillery at orange.com>:
Hello all,

   Here is a third update of our draft for the User Questioning API,

Regards,

Nicolas


_________________________________________________________________________________________________________________________



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<mailto:Openid-specs-mobile-profile at lists.openid.net>

http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile


_________________________________________________________________________________________________________________________

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


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