<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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) 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>
<br>
<div class="moz-cite-prefix">Am 16.08.2016 um 09:17 schrieb Manger,
James:<br>
</div>
<blockquote
cite="mid:255B9BB34FB7D647A506DC292726F6E13BFEBD475E@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;}
/* 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:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
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]-->
<div class="WordSection1">
<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">--<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-AU">James
Manger<o:p></o:p></span></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-mobile-profile mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-mobile-profile@lists.openid.net">Openid-specs-mobile-profile@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</a>
</pre>
</blockquote>
<br>
</body>
</html>