<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Nicolas,<br>
<br>
here are my comments.<br>
<br>
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.<br>
<br>
Major findings:<br>
<br>
- 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? <br>
<br>
- 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. <br>
<br>
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.<br>
<br>
My proposal is:<br>
- the user questioning result returns the question_id (which works
across the different modes) and HTTP status code 200.<br>
- 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. <br>
- push: can stay "as is"<br>
<br>
I know this is not RESTful, but it fits with the design principles
of the rest of the protocol suite.<br>
<br>
- 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<br>
<br>
- 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)<br>
<br>
- I recommend you to fill the security/privacy sections soon since
those sections are a pre-requisite to move the draft forward<br>
<br>
smaller findings:<br>
<br>
section 1<br>
- "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.<br>
<br>
section 2<br>
- 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. <br>
<br>
2.2.1<br>
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<br>
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?“<br>
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?<br>
<br>
section 3<br>
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
question_id - Which entity is supposed to create it?<br>
iss - Isn't this always the OP? If so, pls. state it.<br>
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? <br>
<title></title>
<meta name="generator" content="LibreOffice 5.1.5.2 (Windows)">
<style type="text/css">
@page { margin: 2cm }
dt { color: #000000; font-family: "verdana", "helvetica", "arial", sans-serif; font-size: 10pt }
p { color: #000000; font-family: "verdana", "helvetica", "arial", sans-serif; font-size: 10pt }
a:visited { text-decoration: none }
a:link { text-decoration: none }
</style>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.<br>
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.<br>
<br>
"User Statement Tokens MUST be signed ...." - Which entity is
supposed to sign it, which entity is supposed to decrypt it?<br>
<br>
Example statements: No quotation marks for JSON numbers<br>
<br>
section 4<br>
<br>
I think formating of the text could be simplified and should be
extended.<br>
<br>
Here is my proposal: <br>
<br>
"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". <br>
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. "<br>
<br>
section 5.2<br>
<br>
on the client_notification_endpoint / to the
client_notification_endpoint<br>
<br>
section 6.1<br>
<br>
Intro should state something about use of HTTPS/TLS<br>
<br>
section 6.1.1.<br>
<br>
heading "Request with User Questioning Request" -> "User
Questioning Request"<br>
<br>
"The HTTP POST request contains the following header" -> "The
HTTP POST request MUST contain the following header"<br>
<br>
request attribute definitions:<br>
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<br>
user_id_type: value range?<br>
<br>
section 6.1.3<br>
<br>
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 (<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc6749#section-5.2">https://tools.ietf.org/html/rfc6749#section-5.2</a>?)<br>
<br>
section 6.2.3<br>
<br>
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? <br>
<br>
best regards,<br>
Torsten.<br>
<br>
<div class="moz-cite-prefix">Am 05.10.2016 um 16:05 schrieb
<a class="moz-txt-link-abbreviated" href="mailto:nicolas.aillery@orange.com">nicolas.aillery@orange.com</a>:<br>
</div>
<blockquote
cite="mid:8577_1475676348_57F508BB_8577_773_1_13b2094e-10c4-4427-8ad6-6dd3050f8ecf@OPEXCLILM7D.corporate.adroot.infra.ftgroup"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US">Hello all,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"> Here is a third update of our draft for the
User Questioning API,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"
lang="EN-US">Nicolas<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
</div>
<pre>_________________________________________________________________________________________________________________________
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.
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-mobile-profile mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-mobile-profile@lists.openid.net">Openid-specs-mobile-profile@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</a></pre>
</blockquote>
<br>
</body>
</html>