<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 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";
color:black;}
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;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:10.0pt;
font-family:"Verdana","sans-serif";
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"Préformaté HTML Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.PrformatHTMLCar
{mso-style-name:"Préformaté HTML Car";
mso-style-priority:99;
mso-style-link:"Préformaté HTML";
font-family:Consolas;
color:black;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:612713871;
mso-list-type:hybrid;
mso-list-template-ids:-2070873444 67895297 67895299 67895301 67895297 67895299 67895301 67895297 67895299 67895301;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:1665743076;
mso-list-type:hybrid;
mso-list-template-ids:278542574 67895297 67895299 67895301 67895297 67895299 67895301 67895297 67895299 67895301;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l2
{mso-list-id:1697922965;
mso-list-type:hybrid;
mso-list-template-ids:-11514380 67895297 67895299 67895301 67895297 67895299 67895301 67895297 67895299 67895301;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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]-->
</head>
<body bgcolor="white" lang="FR" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hello Torsten,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> Thanks for your review.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> I give my answers in your text.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Nicolas<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">De :</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
<br>
<b>Envoyé :</b> samedi 15 octobre 2016 12:31<br>
<b>À :</b> AILLERY Nicolas IMT/OLPS; openid-specs-mobile-profile@lists.openid.net<br>
<b>Cc :</b> VASSELET Mickaël IMT/OLN<br>
<b>Objet :</b> Re: [Openid-specs-mobile-profile] [User Questioning API] Third draft<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">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?
<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY]<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l1 level1 lfo1"><![if !supportLists]><span lang="EN-US" style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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. <o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l1 level1 lfo1"><![if !supportLists]><span lang="EN-US" style="font-family:Symbol;color:windowtext"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.</span><span lang="EN-US" style="color:windowtext"><o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l1 level1 lfo1"><![if !supportLists]><span lang="EN-US" style="font-family:Symbol;color:windowtext"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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</span><span lang="EN-US" style="color:windowtext"><o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l1 level1 lfo1"><![if !supportLists]><span lang="EN-US" style="font-family:Symbol;color:windowtext"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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’ ;) ).</span><span lang="EN-US" style="color:windowtext"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><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.
</span>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>
<span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] agreed<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><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.
</span>Moreover, I think the design could be simplified by using a static endpoint for obtaining the result, which takes the question_id as parameter.
<span lang="EN-US">This endpoint should be discovered by the client using the openid-configuration.</span><span lang="EN-US" style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] What is the ‘openid-configuration’ ?</span><span lang="EN-US"><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>
</span>- push: can stay "as is"<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY]<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-bottom:12.0pt;text-indent:-18.0pt;mso-list:l2 level1 lfo3">
<![if !supportLists]><span lang="EN-US" style="font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="color:#1F497D">OK for 200 OK and question_id in both modes<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-bottom:12.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo2">
<![if !supportLists]><span lang="EN-US" style="font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><br>
I know this is not RESTful, but it fits with the design principles of the rest of the protocol suite.<br>
<br>
</span>- The document misses a description of how an user id is determined based on the user_id parameter or the access token.
<span lang="EN-US">I recommend to add it after section 3 and merge it with the text in section 6.1.1.1<br>
</span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] OK<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><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>
</span><span lang="EN-US" style="color:#1F497D">[NAY] OK</span><span lang="EN-US"><br>
- I recommend you to fill the security/privacy sections soon since those sections are a pre-requisite to move the draft forward<br>
</span><span lang="EN-US" style="color:#1F497D">[NAY] OK</span><span lang="EN-US"><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."
</span>Meaning of this sentence is unclear to me.<br>
<span lang="EN-US" style="color:#1F497D">[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.”</span><span lang="EN-US"><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>
</span><span lang="EN-US" style="color:#1F497D">[NAY] Due to the limited width allowed for figures by the RFC template, it will be very difficult to do
</span><span lang="EN-US"><br>
2.2.1<br>
1st bullet: "1. </span>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<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] proposition : “The Client needs to have a real-time interaction with an End-User that may not be currently using
the Client.”<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">2nd bullet: "2.
</span>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?“<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] it’s just about semantic here. The Client needs to question the user.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">4th bullet: "4.
</span>The Client needs to have a non-repudiable proof of the End-User's statement. " - Does the current draft fulfill this requirement?<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[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.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">section 3<br>
question_id - Which entity is supposed to create it?</span><span lang="EN-US" style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] the OP<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">iss - Isn't this always the OP?
</span>If so, pls. state it.<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] In this specification, only the OP can sign. In the future, the user’s device should be allowed to do so.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">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?
</span><span lang="EN-US" style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] OK<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">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.</span><span lang="EN-US" style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] done<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">used_qcr/used_qmr: The description makes obvious we are talking about the ACR of the authentication used in the context of the questioning.
</span>So no need to introduce new terminology - I would suggest to use a term like used_acr or at best just acr and amr.<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[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.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><br>
<br>
"User Statement Tokens MUST be signed ...." - Which entity is supposed to sign it, which entity is supposed to decrypt it?</span><span lang="EN-US" style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] Signed by the OP, verified by the Client. Encryption is optional.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><br>
Example statements: No quotation marks for JSON numbers</span><span lang="EN-US" style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] done</span><span lang="EN-US"><br>
<br>
section 4<br>
<br>
I think formating of the text could be simplified and should be extended.<br>
<br>
</span>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. "<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] Done, but splitted in two paragraphs.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><br>
section 5.2<br>
<br>
on the client_notification_endpoint / to the client_notification_endpoint</span><span lang="EN-US" style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] done</span><span lang="EN-US"><br>
<br>
section 6.1<br>
<br>
Intro should state something about use of HTTPS/TLS</span><span lang="EN-US" style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] done<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">section 6.1.1.<br>
<br>
</span>heading "Request with User Questioning Request" -> "User Questioning Request"<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] done</span><span lang="EN-US"><br>
<br>
"The HTTP POST request contains the following header" -> "The HTTP POST request MUST contain the following header"</span><span lang="EN-US" style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] done</span><span lang="EN-US"><br>
<br>
request attribute definitions:<br>
client_notification_token: "MANDATORY if the Client uses the Pushed-To-Client Flow described in Section 5.2.
</span>IGNORED otherwise." - I would suggest any deviation from the spec should cause an error – ignoring such mistakes may lead to undiscovered errors == problems<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] OK<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">user_id_type: value range?</span><span lang="EN-US" style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] I added a reference to §6.1.1.1<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">section 6.1.3<br>
<br>
Which purpose serves the additional JSON member "error_info"? </span>I would suggest to stick to the definition of the error response given in RFC 6749 (<a href="https://tools.ietf.org/html/rfc6749#section-5.2">https://tools.ietf.org/html/rfc6749#section-5.2</a>?)<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] agreed</span><span lang="EN-US"><br>
<br>
section 6.2.3<br>
<br>
question_id is contained in the request URL, the response payload and the statement.
</span>Is there any validation logic the client is supposed to perform to ensure the consistency?
<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[NAY] I added a ‘SHOULD check equality’<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><br>
<br>
best regards,<br>
Torsten.</span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">Am 05.10.2016 um 16:05 schrieb </span><a href="mailto:nicolas.aillery@orange.com"><span lang="EN-US">nicolas.aillery@orange.com</span></a><span lang="EN-US">:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hello all,</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> Here is a third update of our draft for the User Questioning API,</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Regards,</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Nicolas</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> </span><o:p></o:p></p>
<pre>_________________________________________________________________________________________________________________________<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc<o:p></o:p></pre>
<pre>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler<o:p></o:p></pre>
<pre>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,<o:p></o:p></pre>
<pre>Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>This message and its attachments may contain confidential or privileged information that may be protected by law;<o:p></o:p></pre>
<pre>they should not be distributed, used or copied without authorisation.<o:p></o:p></pre>
<pre>If you have received this email in error, please notify the sender and delete this message and its attachments.<o:p></o:p></pre>
<pre>As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.<o:p></o:p></pre>
<pre>Thank you.<o:p></o:p></pre>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Openid-specs-mobile-profile mailing list<o:p></o:p></pre>
<pre><a href="mailto:Openid-specs-mobile-profile@lists.openid.net">Openid-specs-mobile-profile@lists.openid.net</a><o:p></o:p></pre>
<pre><a href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></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></body>
</html>