<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:x="urn:schemas-microsoft-com:office:excel" 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: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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";
        mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
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:11.0pt;
        font-family:"Calibri","sans-serif";
        mso-fareast-language:EN-US;}
span.EmailStyle18
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.EmailStyle19
        {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:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:218980873;
        mso-list-type:hybrid;
        mso-list-template-ids:1047659854 67895311 67895321 67895323 67895311 67895321 67895323 67895311 67895321 67895323;}
@list l0:level1
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level2
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level3
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l0:level4
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level5
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level6
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l0:level7
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level8
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level9
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
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 lang="FR" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Hello James,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">   Here are my comments.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Nicolas<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">PS: draft 10 has been pusblished<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="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";mso-fareast-language:FR">De :</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-language:FR"> Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces@lists.openid.net]
<b>De la part de</b> Manger, James<br>
<b>Envoyé :</b> mercredi 7 décembre 2016 07:47<br>
<b>À :</b> openid-specs-mobile-profile@lists.openid.net<br>
<b>Objet :</b> [Openid-specs-mobile-profile] UQ comments<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-AU">Comments on OpenID Connect User Questioning API <draft-user-questioning-api-09> (UQ):<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU">Overall<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span lang="EN-AU"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]><span lang="EN-AU">Combine UQ and CIBA —<br>
Their use-cases (confirming answers vs confirming a login) are on the same continuum and there is a lot of overlap in functionality. They differ in some design choices (new endpoint vs reuse token endpoint; access_token vs client cred; …), but these are exactly
 the choices where we should standardize on one choice. Where we are really unable to reach consensus on one choice, put in both options. At least each choice becomes more apparent.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">[NAY] UQ and CIBA are both server to server API, but I don’t think they offer the same functions and address the same use cases. Merging them on the basis that they are server to server API would
 be a shortcut.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">UQ API aims at questioning a user and returning an OP asserted answer to the Client. The Client can then enforce its policy. We gave a list of business use cases where this feature is useful.
<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">About CIBA, nor CIBA features neither addressed use cases are clear for us. In our understanding, CIBA is interesting when there is no UA and the OP has to deliver an Access Token (i.e. an access
 right to OP’s APIs). The business use cases for this are not clear.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span lang="EN-AU"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]><span lang="EN-AU">[2] The signed statement only covers the chosen answer, not the other choices. This could be misleading? For instance, an answer to example #6 in §1.5 ("Which is your favorite brand?") could be "brand_B", but
 that could mean you favour B over A & C; or you favour B over D (but would have favoured A if it was a choice). Include all the choices in the signed statement, along with an indication of the chosen one.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">[NAY] Agreed. ‘displayed_statements’ added in the User Statement Token in draft 10.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU">Other comments<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span lang="EN-AU"><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]><span lang="EN-AU">[Abstract] Mention that an OP is involved.<br>
"This specification defines an API offered by an OpenID Provider (OP) that can be used by an application to send a question to a user of the OP. The user does not need to be interacting with the application when the question is asked. The user's answer is returned
 asynchronously, digitally-signed by the OP."<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">[NAY] Agreed. Modified in draft 10.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span lang="EN-AU"><span style="mso-list:Ignore">4.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]><span lang="EN-AU">[1.3] "its digitally signed response" implies the user does the signing, but actually the OP does.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">[NAY] Agreed. Modified in draft 10.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span lang="EN-AU"><span style="mso-list:Ignore">5.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]><span lang="EN-AU">[1.4.1, 1.4.2] Move the common sentence about (2a) to 1.3 since it is common to pull & push flows.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">[NAY] Agreed. Modified in draft 10.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-AU">6.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif"">      
</span><span lang="EN-AU">[1] Mention that the question and any multiple-choice answers are each a short textual message; perhaps including 1 example.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">[NAY] Agreed. Modified in draft 10.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU">        7.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif"">      
</span><span lang="EN-AU">[2] The answer (user statement token) is described before the question (4.1.1 User Questioning Request), which isn't the most intuitive arrangement.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">[NAY] we reused the OIDC Core structure. I see no elegant place to put this chapter.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-AU">8.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif"">      
</span><span lang="EN-AU">[2] I assume "question_id" identifies a specific instance of asking a user a question. It isn't an id just for a question itself, which could be posed to many users many times. Perhaps "request_id" would be a better label.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">[NAY] Yes, question_id is like a request_id. I’m not sure it’s worth modifying the draft.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-AU">9.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif"">      
</span><span lang="EN-AU">[2] "Do you allow …?" is not a great sample question.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">[NAY] Agreed. Modified in draft 10.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-AU">10.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif"">  
</span><span lang="EN-AU">[2] There is no single field that ensures the semantics of the signed statement are unambiguous. How about setting the "typ" parameter to "openid-connect-user-question"?<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">[NAY] The UQ API delivers User Statement Tokens and these tokens have a specific structure (question_id, displayed_question, displayed_statements, statement). Except if this ‘typ’ is added to
 all OIF specifications, I don’t see benefits in the UQ API case.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-AU">11.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif"">  
</span><span lang="EN-AU">[2] Can't we use "amr" & "acr", instead of "used_amr" & "used_acr"?<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">[NAY] We could amr and acr, but as there are amr/acr in the User Questioning Request and amr/acr in the User Statement Token, and as those amr/acr doesn’t have semantic<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-AU">12.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif"">  
</span><span lang="EN-AU">[2] Why not "iat" (issued at), instead of defining a new "statement_date"?<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">[NAY] ‘iat’ stands for the JWT creation date. In this API, the ‘statement_date’ is more important. ‘iat’ could be added, but I don’t see relevant use case for it.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-AU">13.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif"">  
</span><span lang="EN-AU">[4.1.1] Uses a mix of SHALL and MUST; better to consistently use one.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">[NAY] Agreed. Modified in draft 10.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-AU">14.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif"">  
</span><span lang="EN-AU">[4.1.1] An OP returning the auth method used (amr) is okay, but clients shouldn’t be able to ask for specific methods. It’s too fragile; too likely to break when a new method is introduced. Clients asking for an acr is at a better
 level.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">[NAY] We added the ‘wished_amr’ because it’s a need we already have on our OIDC implementation. Today, we have to deal with specific client_id or other tricks. Having an optional ‘wished_amr’
 would have helped a lot. It’s the reason why we want it in the UQ API.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-AU">15.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif"">  
</span><span lang="EN-AU">[4.1.1] Can’t really say “MUST be displayed with no modification” then in the very next sentence say “if modifications occur…”. Rephrase as “SHOULD NOT be modified…, the only exception being…”<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">[NAY] Agreed. Modified in draft 10.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-AU">16.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif"">  
</span><span lang="EN-AU">[4.2.1] I doubt an HTTP header (Client_timeout ) is a good idea to indicate client support for long polling, unless there is a standard HTTP header for this. How about another query string parameter? We should add some suggested wait
 time (and servers should accept anything larger). I don’t know much about long polling in practice, but it sounds like 20s is about the max to try.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">[NAY] Agreed. Before modifying the draft, I prefer to wait for a common OIF approach on polling.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-AU">17.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif"">  
</span><span lang="EN-AU">[4.2.3] 304 Not Modified isn't the right polling status when the statement is still pending. Can't return 304 if no previous content has been sent for a URI. 202 “Accepted” might be a better choice.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">[NAY] Agreed. It’s from the early drafts when we used to return content. Before modifying the draft, I prefer to wait for a common OIF approach on polling.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-AU">18.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif"">  
</span><span lang="EN-AU">[4.3.4] Can the RP's notification endpoint return a redirect that the OP will follow? Hopefully.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:red">[NAY] In the current draft, the HTTP response (from the RP) is ignored. For me, this means not redirect, no retry on error, … On this, I prefer to wait for a common OIF approach on client notification.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0cm"><span lang="EN-AU" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="mso-fareast-language:EN-AU">--<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="mso-fareast-language:EN-AU">James Manger<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU"><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></body>
</html>