<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi James,<br>
<br>
<div class="moz-cite-prefix">Am 24.08.2016 um 01:16 schrieb Manger,
James:<br>
</div>
<blockquote
cite="mid:255B9BB34FB7D647A506DC292726F6E13BFF118A9B@WSMSG3153V.srv.dir.telstra.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<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: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;
color:black;
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;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;
mso-fareast-language:EN-US;}
span.EmailStyle20
{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;}
--></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]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">A single
porting token from the Old OP to the New OP would be nice.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I don’t think
we can simply send that one token in “aka” to every RP in
step 2b below because it defeats the reason for using
pairwise subject ids. It would enable any pair of RPs to
correlate a user’s accounts.</span></p>
</div>
</blockquote>
<br>
You are right - I oversaw this consequence.<br>
<br>
<blockquote
cite="mid:255B9BB34FB7D647A506DC292726F6E13BFF118A9B@WSMSG3153V.srv.dir.telstra.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Perhaps a
slight variant could work:<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">2b) the New OP
adds to the id_token an "aka" member identifying the Old OP
and holding an encrypted version of the port_token. The
port_token is encrypted with the Old OP’s public key (or
possibly a symmetric key shared by Old & New OPs). The
encryption needs to be performed separately for each RP with
a per-RP nonce. (Formatted as a JWE I guess.)<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">This way each
RP sees a different encrypted_port_token that (hopefully)
cannot be correlated to those seen by other RPs. (An Old OP
might need to be careful that port_tokens are all the same
length so ciphertext length cannot be used as a correlation
handle).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">The Old RP can
decrypt the port_token then proceed as below.<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">One downside of
the Old OP not indicating known RPs for a specific user to
the New OP is that the New OP has to send the
encrypted_port_token to every RP. Every RP will check with
the Old OP (except an RP that knows it has no users using
that Old OP). Consequently the Old OP learns about new RPs
that the user starts using after they ported, which is a bit
unfortunate. The New OP could ask the user (with a checkbox
on a login/consent page) if he or she already has an account
at a given RP federated from the Old OP, but that isn’t too
appealing.</span></p>
</div>
</blockquote>
<br>
I think this is a reasonable solution (and potentially the only
one).<br>
<br>
I think even the old OP cannot always decide whether it asserted a
certain account to a particular RP. So we somehow need to account
for this uncertainity. In my draft, the old OP would use the public
subject (if available). In your proposal, the old OP can decide
(based on RP policy, user data, user consent...., whatever logic it
wants to apply) if and what subject to assert. <br>
<br>
best regards,<br>
Torsten.<br>
<br>
<blockquote
cite="mid:255B9BB34FB7D647A506DC292726F6E13BFF118A9B@WSMSG3153V.srv.dir.telstra.com"
type="cite">
<div class="WordSection1">
<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">--<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>
<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
style="color:windowtext;mso-fareast-language:EN-AU"
lang="EN-US">From:</span></b><span
style="color:windowtext;mso-fareast-language:EN-AU"
lang="EN-US"> Torsten Lodderstedt
[<a class="moz-txt-link-freetext" href="mailto:torsten@lodderstedt.net">mailto:torsten@lodderstedt.net</a>] <br>
<b>Sent:</b> Wednesday, 24 August 2016 1:21 AM<br>
<b>To:</b> Manger, James
<a class="moz-txt-link-rfc2396E" href="mailto:James.H.Manger@team.telstra.com"><James.H.Manger@team.telstra.com></a>;
<a class="moz-txt-link-abbreviated" href="mailto:openid-specs-mobile-profile@lists.openid.net">openid-specs-mobile-profile@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-mobile-profile]
Alternative account porting design<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi James,<br>
<br>
thanks for writing down your proposal.<br>
<br>
One question directly popped up in my mind: Why does the old
OP issue per RP/sector id porting tokens? This requires the
new OP to correctly co-relate RPs and the corresponding
porting tokens (which in turn seems to correspond to
particular subject values). Identifying RPs is one of the open
issues of my draft and it retains an open issue in your draft
as well. It won't reliably work for native apps (and in the
end break encapsulation of the old OP). Your design has the
potential to deal with it by just letting the old OP do this
part of the job. <br>
<br>
Let me explain how:<br>
I personally think a single porting token representing the old
OP account should suffice. Everything else can be done by the
old OP using the data/credentials at hand (because the RP is
also known to the old OP!).<br>
<br>
1) old OP issues a single porting token (related to the ported
OP account) to the new OP<br>
2) the new OP stores this porting token (along with the iss
value of the old OP) with its corresponding OP account<br>
2<span style="color:red">b</span>) new OP adds "aka" (I like
that name :-)) to the ID token with every login response for
such an account<br>
3) RP sends request to porting check API at the old OP,
including the porting token + the credentials it regularily
uses to identify/authenticate with the tokens endpoint of this
particular OP (it must have an identity with this OP as it is
a RP for this OP as well)<br>
4) the old OP applies the same logic as for a regular login
request, i.e. it authenticates the RP and determines the
appropriate subject value (based on its RP-specific policy and
other data)<br>
5) the old OP returns this subject value (public or pairwise)
to the RP<br>
6) RP uses the subject value to find local account<br>
<br>
Benefit: the old OP is able to determine the RP's identity and
the correct subject value. Moreover, it stays in full control
of which data is handed of to what RP. The new OP does not
need to know anything about the different local accounts
associated with the ported OP account.<br>
<br>
What do you think?<br>
<br>
best regards,<br>
Torsten.<br>
<br>
<span style="font-size:12.0pt;mso-fareast-language:EN-AU"><o:p></o:p></span></p>
<div>
<p class="MsoNormal">Am 16.08.2016 um 09:17 schrieb Manger,
James:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Hi MODRNA,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Attached is an alternative technical
design to support porting between OPs.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> OpenID Connect Account Porting<o:p></o:p></p>
<p class="MsoNormal"> draft-account-porting-00<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> Abstract: This document specifies
mechanisms to support a user porting from<o:p></o:p></p>
<p class="MsoNormal"> one OpenID Connect Provider to another,
such that relying parties can<o:p></o:p></p>
<p class="MsoNormal"> automatically recognize and verify the
change.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">It requires an RP to make an API call to
the Old OP to confirm a port, instead of handling an extra
JWT signed by the Old OP.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">It use a port_token (per user per RP) to
link a porting event across interactions from the Old OP to
the New OP, then to the RP, then back to the Old OP. A
port_token is opaque to the New OP and RP so it could be a
structured value (such as a JWT) if desired by the Old OP to
minimize state in an implementation; otherwise a 256-bit
base64url-encoded random value referencing the porting state
will do.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">It does NOT require an OAuth 2.0 dance by
the RP to confirm a port. It assumes the port_token acts
like a capability (not unlike a bearer access token).<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">It uses Sector Ids to identify (groups of
related) RPs.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">It supports chaining of multiple ports if
required.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">The Security Considerations are copied
unchanged from draft-account-migration-02.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Annex A is an example in the form of a
sequence diagram (embedded with a data: URL).<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">It does require that an Old OP remains
available until RPs have confirmed ports (which could be
months later). However, those responses could be implemented
with a static web site if required so I do think this need
be an onerous burden or risk.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">[1] Torsten’s current draft design using
JWTs: <a moz-do-not-send="true"
href="http://openid.net/wordpress-content/uploads/2016/08/draft-account-migration-02.html">http://openid.net/wordpress-content/uploads/2016/08/draft-account-migration-02.html</a><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-AU">--</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-AU">James
Manger</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman",serif;mso-fareast-language:EN-AU"><br>
<br>
<br>
<o:p></o:p></span></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Openid-specs-mobile-profile mailing list<o:p></o:p></pre>
<pre><a moz-do-not-send="true" href="mailto:Openid-specs-mobile-profile@lists.openid.net">Openid-specs-mobile-profile@lists.openid.net</a><o:p></o:p></pre>
<pre><a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman",serif;mso-fareast-language:EN-AU"><o:p> </o:p></span></p>
</div>
</blockquote>
<br>
</body>
</html>