<div dir="ltr"><div>Hi James, group,<br><br></div><div>I think this proposal is starting to look really solid.  My reflections on the current version:<br></div><div><br>Section 3. <span style="font-family:monospace,monospace">port_token</span> vs <span style="font-family:monospace,monospace">port_token_plain</span>:<br><br></div><div>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:monospace,monospace">port_token</span> results for the <span style="font-family:monospace,monospace">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:monospace,monospace">port_token</span> and <span style="font-family:monospace,monospace">port_token_plain</span>, so all of the heavy lifting in terms of dealing with the described encryption scheme must be implemented anyway.<br><br><div>I suggest dropping the currently specified <span style="font-family:monospace,monospace">port_token</span> result type from the <span style="font-family:monospace,monospace">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.<br></div><br></div><div>Also, I understand that the implication of the <span style="font-family:monospace,monospace">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:monospace,monospace">port_token_seed</span>, perhaps?<br><br>Section 5. Porting check API:<br><br></div><div>I think allowing the RPs to specify the sector id explicitly is a security risk, and suggest that we mandate that RPs authenticate towards the Old OP using HTTP Basic Auth (in the same way as they would towards the <span style="font-family:monospace,monospace">token_endpoint</span>), and that the Old OP resolves the sector id based on the authenticated client id.  Alternatively, we could mandate that the Old OP somehow verifies the given sector id towards the encrypted <span style="font-family:monospace,monospace">port_token</span>, but that would introduce a coupling between the pairwise subject id algorithms of Old and New OP that I understood we wanted to avoid.<br><br></div><div>(For the Mobile Connect specific scenario, adding authentication to this invocation requires that the RPs are able to resolve their Operator Discovery-provided credentials towards the Old OP based solely on the <span style="font-family:monospace,monospace">iss</span> value. I suggest that we presume that the Operator Discovery facility will be able to assist with this at some point in the future.  Should that turn out to not be possible, a fallback strategy could be to make the OPs include a member <span style="font-family:monospace,monospace">mc_od_identity</span> in their configuration document, with values like e.g <span style="font-family:monospace,monospace">"<a href="https://discover.mobileconnect.io/telenor_group/v2/discovery?Redirect_URL=http://localhost/&Selected-MCC=242&Selected-MNC=01">https://discover.mobileconnect.io/telenor_group/v2/discovery?Redirect_URL=http://localhost/&Selected-MCC=242&Selected-MNC=01</a>"</span><span style="font-family:arial,helvetica,sans-serif">. Mobile Connect RPs could then invoke this endpoint using their Operator Discovery credentials to obtain credentials appropriate for use towards the Old OP's <span style="font-family:monospace,monospace">port_check</span> endpoint.)<br><br></span></div><div><span style="font-family:arial,helvetica,sans-serif">BR,<br><br></span></div><div><span style="font-family:arial,helvetica,sans-serif">Arne.<br></span></div><div><span style="font-family:monospace,monospace"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 22, 2016 at 10:30 AM, Manger, James <span dir="ltr"><<a href="mailto:James.H.Manger@team.telstra.com" target="_blank">James.H.Manger@team.telstra.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div link="#0563C1" vlink="#954F72" lang="EN-AU"><div><p class="MsoNormal">Attached is an updated draft of OpenID Connect Account Porting: draft-account-porting-01.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Or read it at <a href="https://id.cto.telstra.com/2016/openid/draft-account-porting.html" target="_blank">https://id.cto.telstra.com/<wbr>2016/openid/draft-account-<wbr>porting.html</a><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I will put it in the <a href="https://bitbucket.org/openid/mobile/src/" target="_blank">Bitbucket repo</a>, once I have sorted out some glitches. [There are 2 “default” branches after Gonzalo’s recent commits, which is hiding earlier commits by John, Joerg, and I. A merge should do it, if I can work out how.]<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">The main change in this draft is that the New OP collects a single token from the Old OP representing a porting event. The New OP needs to bind it to a sector_id and anonymizes it before passing it to RPs — which is done by applying symmetric authenticated encryption, keyed with H(client_secret).<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">This draft does NOT require RPs to authenticate to the Old OP. It assume the encrypted port token can act as a bearer token (ie a capability).<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">There is a pretty flow diagram in appendix A. This time in SVG instead of a PNG.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Comments welcome, indeed required.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><span>--<u></u><u></u></span></p><p class="MsoNormal"><span>James Manger<u></u><u></u></span></p><p class="MsoNormal"><u></u> <u></u></p></div></div><br>______________________________<wbr>_________________<br>
Openid-specs-mobile-profile mailing list<br>
<a href="mailto:Openid-specs-mobile-profile@lists.openid.net">Openid-specs-mobile-profile@<wbr>lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile" rel="noreferrer" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>mobile-profile</a><br>
<br></blockquote></div><br></div>