[Openid-specs-mobile-profile] [User Questioning API] Third draft
Torsten Lodderstedt
torsten at lodderstedt.net
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>
More information about the Openid-specs-mobile-profile
mailing list