<html>
<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;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 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:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
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";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Texte de bulles Car";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";
        mso-fareast-language:EN-US;}
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.PrformatHTMLCar
        {mso-style-name:"Préformaté HTML Car";
        mso-style-priority:99;
        mso-style-link:"Préformaté HTML";
        font-family:Consolas;
        mso-fareast-language:EN-US;}
span.EmailStyle20
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
p.HTMLPreformatted, li.HTMLPreformatted, div.HTMLPreformatted
        {mso-style-name:"HTML Preformatted";
        mso-style-link:"HTML Preformatted Char";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";
        mso-fareast-language:EN-US;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;
        mso-fareast-language:EN-US;}
span.EmailStyle23
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle24
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.TextedebullesCar
        {mso-style-name:"Texte de bulles Car";
        mso-style-priority:99;
        mso-style-link:"Texte de bulles";
        font-family:"Tahoma","sans-serif";
        mso-fareast-language:EN-US;}
.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:266547709;
        mso-list-type:hybrid;
        mso-list-template-ids:1290945392 1426085780 67895321 67895323 67895311 67895321 67895323 67895311 67895321 67895323;}
@list l0:level1
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        margin-left:36.75pt;
        text-indent:-18.75pt;}
@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="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Hi James,<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">  Thanks for the review.<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">   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="MsoListParagraph" style="margin-left:36.75pt;text-indent:-18.75pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang="EN-AU" style="color:#1F497D"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]><span lang="EN-AU" style="color:#1F497D">This doesn’t define general async capabilities for the /token endpoint. It defines async for the one specific case of swapping a JWT for an access token.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:36.75pt"><span lang="EN-AU" style="color:#1F497D">--[Nicolas]-- The goal of this spec is to propose an async extension to the JWT Bearer grant type defined in RFC7523. This will cover the GSMA needs. We could also
 define a generic way to offer async capabilities to /token, extending the RFC6749 (OAuth 2.0). This would entail 3 specifications: “Async /token”, then “Async JWT profile” (the current draft), then “server-to-server Connect profile”. I’d like the advice of
 the working group on these approaches. On my side, both are Ok.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:36.75pt"><span lang="EN-AU" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:36.75pt;text-indent:-18.75pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang="EN-AU" style="color:#1F497D"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]><span lang="EN-AU" style="color:#1F497D">Separate grant_type values indicating poll & push support would be better than one …jwt-bearer:versatile value. The client needs to know the difference to know whether or not to include
 a client_notification_token (and whether or not it needs to be listening for notifications). The AS needs to know the difference to respond correctly. Separate values allow the AS to indicate support for poll, push, both, or neither by listing 0, 1 or both
 separate values in grant_types_supported in its metadata.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:#1F497D">--[Nicolas]-- OK to support 3 grant-types: ‘push’ and ‘poll’ in the first request then ‘polling’ in the polling request. I think the grant_type ‘both’ is not necessary. I’ll update the draft.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:36.75pt"><span lang="EN-AU" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:36.75pt;text-indent:-18.75pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang="EN-AU" style="color:#1F497D"><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]><span lang="EN-AU" style="color:#1F497D">A POSTed notification doesn’t have an HTTP status code to distinguish success and error; both are JSON objects. The spec should explicitly state that the absence or presence of an “error”
 member in the JSON object distinguishes these cases.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:36.75pt"><span lang="EN-AU" style="color:#1F497D">[Nicolas]-- Neither CIBA nor UserQuestioning have a status code in notifications. In UQ, it was present in the first drafts and removed on working group’s request.
 I suggest to use no ‘status’, except if the working group changes its mind.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:36.75pt"><span lang="EN-AU" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:36.75pt;text-indent:-18.75pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang="EN-AU" style="color:#1F497D"><span style="mso-list:Ignore">4.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]><span lang="EN-AU" style="color:#1F497D">The properties required for a transaction_id are not clear, and I suspect they are quite different for the poll & push cases. Can it be a counter (1,2,3,…)? Can it repeat after the “expires_in”
 time? In the polling case, transaction_id acts as a bearer token; it would be better renamed poll_token. In the push case, it can probably be ignored as the client can use client_notification_token to link request & notification.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:36.75pt"><span lang="EN-AU" style="color:#1F497D">--[Nicolas]-- A counter could be OK, but as Client authentication is optional in RFC7523, it’s better to have a random transaction_id with good entropy and no repeatition.
 I’ll update the draft to mention it. As the client_notification_token is chosen by the Client, it’s good to keep the transaction_id so that there can be entropy in the notification even when the Client enforces low security in its client_notification_token.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-AU" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:36.75pt;text-indent:-18.75pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang="EN-AU" style="color:#1F497D"><span style="mso-list:Ignore">5.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]><span lang="EN-AU" style="color:#1F497D">Is it okay for a client to always use the same client_notification_token with a given AS (basically treat it as the AS’s password)? Probably yes, just not recommended due to revocation
 implications.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:36.75pt"><span lang="EN-AU" style="color:#1F497D">--[Nicolas]-- It’s Ok but not recommended for a Client to reuse the client_notification_token. Can you detail what you mean by “revocation implications”, not sure
 to understand?<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:36.75pt"><span lang="EN-AU" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:36.75pt;text-indent:-18.75pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang="EN-AU" style="color:#1F497D"><span style="mso-list:Ignore">6.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]><span lang="EN-AU" style="color:#1F497D">Need IANA registrations for client_notification_token, transaction_id (or whatever it is renamed to), authorization_pending, slow_down, and the other error codes if existing ones cannot
 be reused<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:36.75pt"><span lang="EN-AU" style="color:#1F497D">--[Nicolas]-- Ok for “client_notification_token”, “transaction_id” and the “invalid_transaction_id” error. Other errors come from “draft-ietf-oauth-device-flow-05”,
 shall we refer to this draft?</span><span lang="EN-US" style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D">Regards,<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 style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span 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"> Manger, James [mailto:James.H.Manger@team.telstra.com]
<br>
<b>Envoyé :</b> mercredi 29 mars 2017 03:42<br>
<b>À :</b> AILLERY Nicolas IMT/OLPS; openid-specs-mobile-profile@lists.openid.net<br>
<b>Objet :</b> RE: [Openid-specs-mobile-profile] [Async JWT Profile] draft-oauth-versatile-jwt-profile-01<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D">Hi Nicolas,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D">A couple of comments on the Async JWT Profile:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-AU" style="color:#1F497D">1.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif";color:#1F497D">      
</span><span lang="EN-AU" style="color:#1F497D">This doesn’t define general async capabilities for the /token endpoint. It defines async for the one specific case of swapping a JWT for an access token.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-AU" style="color:#1F497D">2.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif";color:#1F497D">      
</span><span lang="EN-AU" style="color:#1F497D">Separate grant_type values indicating poll & push support would be better than one …jwt-bearer:versatile value. The client needs to know the difference to know whether or not to include a client_notification_token
 (and whether or not it needs to be listening for notifications). The AS needs to know the difference to respond correctly. Separate values allow the AS to indicate support for poll, push, both, or neither by listing 0, 1 or both separate values in grant_types_supported
 in its metadata.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-AU" style="color:#1F497D">3.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif";color:#1F497D">      
</span><span lang="EN-AU" style="color:#1F497D">A POSTed notification doesn’t have an HTTP status code to distinguish success and error; both are JSON objects. The spec should explicitly state that the absence or presence of an “error” member in the JSON object
 distinguishes these cases.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-AU" style="color:#1F497D">4.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif";color:#1F497D">      
</span><span lang="EN-AU" style="color:#1F497D">The properties required for a transaction_id are not clear, and I suspect they are quite different for the poll & push cases. Can it be a counter (1,2,3,…)? Can it repeat after the “expires_in” time? In the polling
 case, transaction_id acts as a bearer token; it would be better renamed poll_token. In the push case, it can probably be ignored as the client can use client_notification_token to link request & notification.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-AU" style="color:#1F497D">5.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif";color:#1F497D">      
</span><span lang="EN-AU" style="color:#1F497D">Is it okay for a client to always use the same client_notification_token with a given AS (basically treat it as the AS’s password)? Probably yes, just not recommended due to revocation implications.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-AU" style="color:#1F497D">6.</span><span lang="EN-AU" style="font-size:7.0pt;font-family:"Times New Roman","serif";color:#1F497D">      
</span><span lang="EN-AU" style="color:#1F497D">Need IANA registrations for client_notification_token, transaction_id (or whatever it is renamed to), authorization_pending, slow_down, and the other error codes if existing ones cannot be reused<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D">--<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D">James Manger<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="mso-fareast-language:EN-AU">From:</span></b><span lang="EN-US" style="mso-fareast-language:EN-AU"> Openid-specs-mobile-profile [<a href="mailto:openid-specs-mobile-profile-bounces@lists.openid.net">mailto:openid-specs-mobile-profile-bounces@lists.openid.net</a>]
<b>On Behalf Of </b><a href="mailto:nicolas.aillery@orange.com">nicolas.aillery@orange.com</a><br>
<b>Sent:</b> Wednesday, 29 March 2017 12:44 AM<br>
<b>To:</b> <a href="mailto:openid-specs-mobile-profile@lists.openid.net">openid-specs-mobile-profile@lists.openid.net</a><br>
<b>Subject:</b> [Openid-specs-mobile-profile] [Async JWT Profile] draft-oauth-versatile-jwt-profile-01<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-AU"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Hello everybody,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">   Please find in attachment a first draft of a JWT Assertion profile enabling both synchronous and asynchronous interactions.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">   Your review will be welcome,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Nicolas</span><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>