<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=utf-8"><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;}
/* 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-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
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 style='margin-bottom:12.0pt'>Hi Arne,<o:p></o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>> Section 3. <span style='font-family:"Courier New"'>port_token</span> vs <span style='font-family:"Courier New"'>port_token_plain</span>:<o:p></o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>> Do we need both flows?<o:p></o:p></p><p class=MsoNormal>The idea was to avoid the encrypt/decrypt complexity when public (not pairwise) subs were being used. Thinking about it more, that only works if both Old and New OPs use public subs. Even if the Old OP uses public subs, it should still use port_token_plain (to be encrypted/decrypted) in case the New OP uses pairwise subs — and the Old OP doesn’t really know what type of subs the New OP will use.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>So I agree we should drop the port_token option from the port_data endpoint.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> <span style='font-family:"Courier New"'>port_token_plain</span> … Can we call it <span style='font-family:"Courier New"'>port_token_seed</span>, perhaps?<br><br><o:p></o:p></p><p class=MsoNormal>…_seed doesn’t have quite the right connotation to me. How about:<o:p></o:p></p><p class=MsoNormal>port_token (renaming port_token_plain in port_data_endpoint response); and<o:p></o:p></p><p class=MsoNormal>enc_port_token (renaming port_token in aka member)?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'>--<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'>James Manger<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Arne Georg Gleditsch [mailto:argggh@telenordigital.com] <br><b>Sent:</b> Tuesday, 27 September 2016 3:18 AM<br><b>Subject:</b> Re: [Openid-specs-mobile-profile] Account porting: draft -01: New OP encrypting port_token<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Hi James, group,<o:p></o:p></p></div><div><p class=MsoNormal>I think this proposal is starting to look really solid. My reflections on the current version:<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'><br>Section 3. <span style='font-family:"Courier New"'>port_token</span> vs <span style='font-family:"Courier New"'>port_token_plain</span>:<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Do we need both flows? I recognize that the mechanics of encrypting and decrypting the port token represent additional complexity that some IdP implementors would prefer to avoid, and that only supplying <span style='font-family:"Courier New"'>port_token</span> results for the <span style='font-family:"Courier New"'>port_data</span> endpoint would allow them to skip implementing the decryption part for when they act in the capacity of "Old OP". However, when acting in the capacity of "New OP", every OP needs to be prepared to deal with both <span style='font-family:"Courier New"'>port_token</span> and <span style='font-family:"Courier New"'>port_token_plain</span>, so all of the heavy lifting in terms of dealing with the described encryption scheme must be implemented anyway.<o:p></o:p></p><div><p class=MsoNormal>I suggest dropping the currently specified <span style='font-family:"Courier New"'>port_token</span> result type from the <span style='font-family:"Courier New"'>port_data</span> endpoint, unless we envision scenarios where (a significant numer of) OPs will act only as "Old OP" and never "New OP", or there are other arguments for keeping it.<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Also, I understand that the implication of the <span style='font-family:"Courier New"'>port_token_plain</span> field name is that the given token has not been encrypted <i>yet</i>, but I still find it a bit confusing, seeing as it signals that the encryption flow should be triggered. Can we call it <span style='font-family:"Courier New"'>port_token_seed</span>, perhaps?<br><br><span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>…<o:p></o:p></span></p></div></div></div></body></html>