<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 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Segoe UI";
panose-1:2 11 5 2 4 2 4 2 2 3;}
@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:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",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.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.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Segoe UI",sans-serif;
mso-fareast-language:EN-US;}
p.PrformatHTML, li.PrformatHTML, div.PrformatHTML
{mso-style-name:"Préformaté HTML";
mso-style-link:"Préformaté HTML Car";
margin:0cm;
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;}
p.Textedebulles, li.Textedebulles, div.Textedebulles
{mso-style-name:"Texte de bulles";
mso-style-link:"Texte de bulles Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
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;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle27
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle28
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle29
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle30
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle31
{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;}
--></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="EN-AU" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Looks good.<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">Instead of §3 for both poll & push initial requests (even though they use different grant_types and different parameters), then separate sections §4 & §5 the rest of those flows, why not have 3 sections for the
3 grant_types?<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">You don’t need to repeat the IANA registrations that
</span><span style="color:#1F497D">draft-ietf-oauth-device-flow makes.<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">There is one “…:push” in 4.2.2 that should be “…:push_mode”<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">Saying “The "xx" attribute contains the "xx" value” feels unnecessary.</span><span style="color:#1F497D"><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">I wasn’t making any suggestion with comment #1 below. I was just reflecting on the design.<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>
<p class="MsoNormal"><span style="color:#1F497D">James Manger<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 #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"> nicolas.aillery@orange.com [mailto:nicolas.aillery@orange.com]
<br>
<b>Sent:</b> Saturday, 1 April 2017 2:12 AM<br>
<b>To:</b> Manger, James <James.H.Manger@team.telstra.com><br>
<b>Cc:</b> openid-specs-mobile-profile@lists.openid.net; MARAIS Charles IMT/OLPS <charles.marais@orange.com>; CLEMENT Philippe IMT TECHNO <philippe.clement@orange.com>; MARIOTTE Hubert IMT/OLN <hubert.mariotte@orange.com><br>
<b>Subject:</b> [Async JWT Profile] draft-oauth-versatile-jwt-profile-02<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="FR" style="color:#1F497D">Hi James,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="FR" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"> Here are my comments inline, and a draft v2,<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">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 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 lang="FR" style="font-size:10.0pt;font-family:"Tahoma",sans-serif;mso-fareast-language:FR">De :</span></b><span lang="FR" style="font-size:10.0pt;font-family:"Tahoma",sans-serif;mso-fareast-language:FR"> Manger, James [<a href="mailto:James.H.Manger@team.telstra.com">mailto:James.H.Manger@team.telstra.com</a>]
<br>
<b>Envoyé :</b> jeudi 30 mars 2017 01:29<br>
<b>À :</b> AILLERY Nicolas IMT/OLPS<br>
<b>Cc :</b> <a href="mailto:openid-specs-mobile-profile@lists.openid.net">openid-specs-mobile-profile@lists.openid.net</a>; MARAIS Charles IMT/OLPS; CLEMENT Philippe IMT TECHNO; MARIOTTE Hubert IMT/OLN<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"><span lang="FR"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">[James] comments inline<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="mso-fareast-language:EN-AU">From:</span></b><span style="mso-fareast-language:EN-AU">
<a href="mailto:nicolas.aillery@orange.com">nicolas.aillery@orange.com</a> [<a href="mailto:nicolas.aillery@orange.com">mailto:nicolas.aillery@orange.com</a>]
<br>
<b>Sent:</b> Thursday, 30 March 2017 12:47 AM</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Hi James,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> Thanks for the review.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> Here are my comments:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:36.75pt;text-indent:-18.75pt">1.<span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span><span 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.</span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:36.75pt"><span 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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">[James] I guess draft-ietf-oauth-device-flow also uses grant_type to indicate async behaviour.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">[Nicolas] Agreed, but I don’t understand what you’d suggest. Merging specs? Reusing grant_types? Renaming the profile?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:36.75pt;text-indent:-18.75pt">2.<span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span><span 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.</span><o:p></o:p></p>
<p class="MsoListParagraph"><span 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.</span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:36.75pt"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0cm"><span style="color:#1F497D">[James] That is exactly what I meant.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0cm"><span style="color:#1F497D">[Nicolas] OK<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0cm"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:36.75pt"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:36.75pt;text-indent:-18.75pt">3.<span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span><span 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.</span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:36.75pt"><span 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.</span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:36.75pt"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:0cm"><span style="color:#1F497D">[James] I wasn’t asking for a ‘status’ member. But for one clear rule in the doc that all clients will use to determines whether the POSTed JSON object is an error or success. The
examples in 5.1 & 5.2 could be distinguished by looking for any of ‘access_token’, ‘token_type’, ‘refresh_token’, ‘expires_in’, ‘error’, or ‘error_description’. Let’s make 1 rule: if the JSON object has an ‘error’ member it’s an error, otherwise it is a successful
token response. That implies a successful response MUST never include an ‘error’ member.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0cm"><span style="color:#1F497D">[Nicolas] Ok. Done.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0cm"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:36.75pt;text-indent:-18.75pt">4.<span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span><span 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.</span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:36.75pt"><span 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.</span><o:p></o:p></p>
<p class="MsoListParagraph"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0cm"><span style="color:#1F497D">[James] Does any client auth on the first call to /token need to be repeated for each subsequent /token polling request? Or is transaction_id (maybe renamed poll_token) sufficient
for those?<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0cm"><span style="color:#1F497D">[Nicolas] If used, the Client authentication must be repeated. Spec updated.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:36.75pt;text-indent:-18.75pt">5.<span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span><span 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.</span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:36.75pt"><span 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?</span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:0cm"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0cm"><span style="color:#1F497D">[James] Ignore the “revocation” bit, I just meant that if you reuse the same value you need a process to change it if it is ever compromised.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:0cm"><span style="color:#1F497D">[Nicolas] Added that client_notification_token should not be reused.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:36.75pt"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:36.75pt;text-indent:-18.75pt">6.<span style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span><span 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</span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:36.75pt"><span 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><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">[James] I forgot about draft-ietf-oauth-device-flow. I guess you don’t really need to refer to that spec as its error codes will make it to the IANA registry.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">[Nicolas] I let a reference to draft-ietf-oauth-device-flow. I’ll change it as soon as the device flow becomes a RFC.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<pre><span lang="FR"><o:p> </o:p></span></pre>
</div>
</body>
</html>