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

Sat Oct 15 10:31:25 UTC 2016

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?

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

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.

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"

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

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

  - I recommend you to fill the security/privacy sections soon since 
those sections are a pre-requisite to move the draft forward

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.

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.

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

section 3
question_id - Which entity is supposed to create it?
iss - Isn't this always the OP? If so, pls. state it.
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?
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.
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.

"User Statement Tokens MUST be signed ...." - Which entity is supposed 
to sign it, which entity is supposed to decrypt it?

Example statements: No quotation marks for JSON numbers

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

section 5.2

on the client_notification_endpoint / to the client_notification_endpoint

section 6.1

Intro should state something about use of HTTPS/TLS

section 6.1.1.

heading "Request with User Questioning Request" -> "User Questioning 
Request"

"The HTTP POST request contains the following header" -> "The HTTP POST 
request MUST contain the following header"

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
user_id_type: value range?

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

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?

best regards,
Torsten.

Am 05.10.2016 um 16:05 schrieb 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
> 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/20161015/e5e62e4b/attachment.html>