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