<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>OpenID Connect Account Migration 1.0</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents"/>
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction"/>
<link href="#rfc.section.1.1" rel="Chapter" title="1.1 Requirements Notation and Conventions"/>
<link href="#rfc.section.1.2" rel="Chapter" title="1.2 Terminology"/>
<link href="#rfc.section.2" rel="Chapter" title="2 Overview"/>
<link href="#rfc.section.3" rel="Chapter" title="3 Migrating a User Account between OPs"/>
<link href="#rfc.section.4" rel="Chapter" title="4 Migrating a User Account at an RP"/>
<link href="#rfc.section.5" rel="Chapter" title="5 Security Considerations"/>
<link href="#rfc.section.6" rel="Chapter" title="6 Privacy Considerations"/>
<link href="#rfc.section.7" rel="Chapter" title="7 IANA Considerations"/>
<link href="#rfc.references" rel="Chapter" title="8 References"/>
<link href="#rfc.references.1" rel="Chapter" title="8.1 Normative References"/>
<link href="#rfc.references.2" rel="Chapter" title="8.2 Informative References"/>
<link href="#rfc.appendix.A" rel="Chapter" title="A Acknowledgements"/>
<link href="#rfc.appendix.B" rel="Chapter" title="B Notices"/>
<link href="#rfc.appendix.C" rel="Chapter" title="C Document History"/>
<link href="#rfc.authors" rel="Chapter"/>
<meta name="generator" content="xml2rfc version 2.5.1.dev0 - http://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Lodderstedt, T." />
<meta name="dct.identifier" content="urn:ietf:id:draft-account-migration-00" />
<meta name="dct.issued" scheme="ISO8601" content="2016-5-08" />
<meta name="dct.abstract" content="This document specifies a protocol for migrating user accounts among OpenID OPs, which is required in the context of Mobile Connect. Furthermore, the design shall be applicable to other contexts as well. The goal of the design is to allow users to migrate between OPs while retaining access to their services (RPs). " />
<meta name="description" content="This document specifies a protocol for migrating user accounts among OpenID OPs, which is required in the context of Mobile Connect. Furthermore, the design shall be applicable to other contexts as well. The goal of the design is to allow users to migrate between OPs while retaining access to their services (RPs). " />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left"></td>
<td class="right">T. Lodderstedt</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">Deutsche Telekom AG</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">MAY 08, 2016</td>
</tr>
</tbody>
</table>
<p class="title">OpenID Connect Account Migration 1.0<br />
<span class="filename">draft-account-migration-00</span></p>
<h1 id="rfc.abstract">
<a href="#rfc.abstract">Abstract</a>
</h1>
<p>This document specifies a protocol for migrating user accounts among OpenID OPs, which is required in the context of Mobile Connect. Furthermore, the design shall be applicable to other contexts as well. The goal of the design is to allow users to migrate between OPs while retaining access to their services (RPs). </p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a></li>
<ul><li>1.1. <a href="#rfc.section.1.1">Requirements Notation and Conventions</a></li>
<li>1.2. <a href="#rfc.section.1.2">Terminology</a></li>
</ul><li>2. <a href="#rfc.section.2">Overview</a></li>
<li>3. <a href="#rfc.section.3">Migrating a User Account between OPs</a></li>
<li>4. <a href="#rfc.section.4">Migrating a User Account at an RP</a></li>
<li>5. <a href="#rfc.section.5">Security Considerations</a></li>
<li>6. <a href="#rfc.section.6">Privacy Considerations</a></li>
<li>7. <a href="#rfc.section.7">IANA Considerations</a></li>
<li>8. <a href="#rfc.references">References</a></li>
<ul><li>8.1. <a href="#rfc.references.1">Normative References</a></li>
<li>8.2. <a href="#rfc.references.2">Informative References</a></li>
</ul><li>Appendix A. <a href="#rfc.appendix.A">Acknowledgements</a></li>
<li>Appendix B. <a href="#rfc.appendix.B">Notices</a></li>
<li>Appendix C. <a href="#rfc.appendix.C">Document History</a></li>
<li><a href="#rfc.authors">Author's Address</a></li>
</ul>
<h1 id="rfc.section.1"><a href="#rfc.section.1">1.</a> <a href="#Introduction" id="Introduction">Introduction</a></h1>
<p id="rfc.section.1.p.1">Mobile Connect uses the mobile phone number to identify a certain user identity. So from a user's perspective, the mobile phone number is becoming her digital identity and is used to login to a variety of services. When the respective subscriber changes among mobile network operators, the mobile phone number is typically migrated and can be used with the new MNO (mobile phone number portability). And in the same way the user can be reached afterwards via the same mobile phone number as before, users may also expect to retain access to all the services they had logged into with this mobile phone number before. </p>
<p id="rfc.section.1.p.2">From a technical perspective, retaining access to the services means to migrate the user id asserted for a certain user account by the old OP to a particular RP to the respective (new) user id asserted by the new OP for the same user identity. This draft proposes a protocol, which allows the new OP to obtain the necessary user data from the old OP and provide every RP with the necessary data to migrate the RP's local user account data in a secure way. The basic idea of the protocol design is to migrate the identifier used to identify the user account at the RP "on-the-fly" while the user is logging into a certain RP using her new OP. </p>
<h1 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1.</a> <a href="#rnc" id="rnc">Requirements Notation and Conventions</a></h1>
<p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a href="#RFC2119">[RFC2119]</a>.</p>
<p id="rfc.section.1.1.p.2">Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value.</p>
<h1 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2.</a> <a href="#terminology" id="terminology">Terminology</a></h1>
<p id="rfc.section.1.2.p.1">This specification uses the terms "OpenID Provider (OP)" and "Relying Party (RP)" as defined by <a href="#OpenID.Core">OpenID Connect Core</a> <cite title="NONE">[OpenID.Core]</cite>. This specification also defines the following terms: </p>
<dl>
<dt>Mobile Network Operator (MNO)</dt>
<dd style="margin-left: 8">A provider of wireless communication services that owns or controls the wireless network elements necessary to sell and deliver services to an end user. </dd>
</dl>
<p> </p>
<h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a href="#overview" id="overview">Overview</a></h1>
<p id="rfc.section.2.p.1">The first section defines the protocol flow for transferring data about a user account to be migrated between old and new OP. The second section describes the extension to the OpenID authentication response and the respective logic to provide the RP with the necessary data to migrate a particular user account "on-the-fly" during the login process. </p>
<h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a href="#mig_ops" id="mig_ops">Migrating a User Account between OPs</a></h1>
<p id="rfc.section.3.p.1">Assumption: when the process starts, the old OP is no longer associated with the mobile phone number.</p>
<p id="rfc.section.3.p.2">(1) The user starts migration explicitly at her new OP. She logs in and starts the account migration process.</p>
<p id="rfc.section.3.p.3">(2) She identifies the old OP (via issuer URL or name)</p>
<p id="rfc.section.3.p.4">(3) The new OP determines the migration endpoint (via OpenID configuration or hard wired) </p>
<p>For example, given the issuer URL https://op.mno1.com, the new OP would obtain the following OpenID configuration of the old OP from https://op.mno1.com/.well-known/openid-configuration (line breaks are for display purposes only):</p>
<pre>HTTP/1.1 200 OK
Content-Type: application/json
{
"issuer":
"https://op.mno1.com",
"authorization_endpoint":
"https://op.mno1.com/connect/authorize",
"token_endpoint":
"https://op.mno1.com/connect/token",
"migration_info_endpoint":
"https://op.mno1.com/connect/migrate",
...
}
</pre>
<p id="rfc.section.3.p.5">Please note: the discovery document contains a new claim migration_info_endpoint referring to a new endpoint used to provide other OPs with user account data in the context of user account migration. </p>
<p id="rfc.section.3.p.6">(4) In the next step, the new OP initiates an authorization for access to the migration info endpoint with the old OP via a standard OAuth code flow.</p>
<pre>GET connect/authorize?client_id=example_client&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fauthz&
state=676863864872641764&scope=migration_info HTTP/1.1
Host: discovery.example.com
</pre>
<p id="rfc.section.3.p.7">(a) The user is redirect to the old OP's authorization endpoint and the OP is asked to permit access to the migration endpoint by using a scope value of "migration_info". </p>
<p id="rfc.section.3.p.8">(b) The User is authenticated by the old OP. The means used for authentication are out of scope of this specification. The OP could use credentials especially issued for migration. It could also use standard mechanisms/credentials other thann Mobile Connect specific authenticators (because those are no longer available at the old OP).</p>
<p id="rfc.section.3.p.9">(c) The old OP issues an authorization code.</p>
<p id="rfc.section.3.p.10">(d) The new OP exchanges this authorization code at the old OP's tokens endpoint for an access token, which valid to invoke the migration info endpoint.</p>
<p/>
<p>(5) The new OP invokes the migration endpoint and obtains the migration data of the respective user account (represented by the access token). </p>
<pre>GET /connect/migrate HTTP/1.1
Host: discovery.example.com
Authorization: Bearer mF_9.B5f-4.1JqM
</pre>
<p/>
<p>The response is a JSON array, which for every RP the respective user account had been used to login to, contains the subject value along with the respective redirect or sector identifier URI (line breaks are for display purposes only): </p>
<pre>HTTP/1.1 200 OK
Content-Type: application/json
[{
"sub": "45445454",
"redirect_uri": "https://creditagency.example.com/oidc",
"porting_data": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJod
HRwczovL29wLm1ubzEuY29tIiwic3ViIjoiNDU0NDU0NTQiLCJhdWQiOiJodHRwczovL
2JhbmsuZXhhbXBsZS5j b20vb2lkYyIsIm1pZ3JhdGVkX3RvIjoiaHR0cHM6Ly9vcC5t
bm8yLmNvbSIsImV4cCI6MTMxMTI4MTk3MCwiaWF0IjoxMzExMjgwOTcwfQ.G6ySs3hGt
tmVgVzRTycuAdnxztHZdl3T4D7nRAigEU"
},{
"sub": "67676766",
"sector_identifier_uri":
"https://bank.example.com/file_of_redirect_uris.json",
"porting_data": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodH
RwczovL29wLm1ubzEuY29tIiwic3ViIjoiNjc2NzY3NjYiLCJhdWQiOiJodHRwczovL2
NyZWRpdGFnZW5jeS5leGFtcGxlLmNvbS9vaWRjIiwibWlncmF0ZWRfdG8iOiJodHRwcz
ovL29wLm1ubzIuY29tIiwiZXhwIjoxMzExMjgxOTcwLCpYXQiOjEzMTEyODA5NzB9.w0
9Qd8ngaLLuNMAgyduO589kB8QE3MtPiaZ3yx3DHhs"
}]
</pre>
<p>The value "porting_data" contains a JWT signed by the old OP, which is used by the new OP to prove that the migration of the user account was authorized by the old OP. </p>
<p id="rfc.section.3.p.13">The porting data JWT contains the following claims: </p>
<dl>
<dt>iss</dt>
<dd style="margin-left: 8">Issuer URL of the OP, which asserted the JWT. Basically the same semantics as in an id token.</dd>
<dt>sub</dt>
<dd style="margin-left: 8">subject identifier of the respective user account for the RP identified by the claim "aud". Basically the same semantics as in an id token.</dd>
<dt>redirect_uri</dt>
<dd style="margin-left: 8">value of the redirect of the RP, for which the OP asserted the subject identifier given in the claim "sub".</dd>
<dt>sector_identifier_uri</dt>
<dd style="margin-left: 8">value of the sector identifier URI of a group of RPs, for which the OP asserted the subject identifier given in the claim "sub". redirect_uri and sector_identifier_uri are mutual exclusive.</dd>
<dt>migrated_to</dt>
<dd style="margin-left: 8">Issuer URL of the OP, the user account has been migrated to.</dd>
</dl>
<p> Note: How is the old OP supposed to determine the issuer URL of the new OP or the new OP in general? </p>
<p>The following shows an example of a porting data JWT: </p>
<pre>
{
"iss": "https://op.mno1.com",
"sub": "45445454",
"redirect_uri": "https://creditagency.example.com/oidc",
"migrated_to": "https://op.mno2.com"
"exp": 1311281970,
"iat": 1311280970
}
</pre>
<p id="rfc.section.3.p.14">(6) The new OP associate the migration data with the respective local account and stores it for later use.</p>
<h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#authn_resp" id="authn_resp">Migrating a User Account at an RP</a></h1>
<p id="rfc.section.4.p.1">The actual migration of user accounts at RPs is performed per RP during the respective login process.</p>
<p id="rfc.section.4.p.2">When generating the authentication response for a particular RP, the new OP verifies, whether it has stored a PPID for the actual user account and the respective RP. A RP is determined to be the same as with the old OP if the redirect_uri or the selector identifier is the same as contained in the data obtained from the migration info endpoint as described above.</p>
<p id="rfc.section.4.p.3">If the OP determines that it has a PPID from the old OP for the particular RP and user account, it adds the respective porting data to the id token. </p>
<p/>
<pre>
{
"iss": "https://op.mno2.com",
"sub": "676887676767",
"aud": "client_xyz",
"porting_data":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL29wLm1ub
zEuY29tIiwic3ViIjoiNDU0NDU0NTQiLCJhdWQiOiJodHRwczovL2JhbmsuZXhhbXBsZS5jb20vb2lkYyIs
Im1pZ3JhdGVkX3RvIjoiaHR0cHM6Ly9vcC5tbm8yLmNvbSIsImV4cCI6MTMxMTI4MTk3MCwiaWF0IjoxMzE
xMjgwOTcwfQ.G6ySs3h-GttmVgVzRTycuAdnxztHZdl3T4D7nRAigEU",
"exp": 1311281970,
"iat": 1311280970,
"auth_time": 1311280969,
"acr": "urn:mace:incommon:iap:silver"
}
</pre>
<p id="rfc.section.4.p.4">The RP is supposed to act as follows:</p>
<p id="rfc.section.4.p.5">If the RP does not find a user account within its database using the combination of the iss and sub claim, it checks whether there exists a porting_data claim in the id token. If that's the case the OP inspects the porting data and attempts to migrate the user account identified by the porting data JWT within its database to the values asserted by the id token.</p>
<p/>
<p>In the example case, the id token carries a porting data claim, which contains the following JWT:</p>
<pre>
{
"iss": "https://op.mno1.com",
"sub": "45445454",
"redirect_uri": "https://creditagency.example.com/oidc",
"migrated_to": "https://op.mno2.com"
"exp": 1311281970,
"iat": 1311280970
}
</pre>
<p id="rfc.section.4.p.7">The RP first validates the digital signature of the porting data JWT. It therefore looks up the old OP's openid configuration and obtains the location of its JWK URL (containing the respective public keys of the OP). </p>
<p>For example, given the issuer URL https://op.mno1.com, the new OP would obtain the following OpenID configuration of the old OP from https://op.mno1.com/.well-known/openid-configuration (line breaks are for display purposes only):</p>
<pre>
HTTP/1.1 200 OK
Content-Type: application/json
{
"issuer": "https://op.mno1.com",
"jwks_uri": "https://op.mno1.com/jwks.json",
...
}
</pre>
<p/>
<p>It then loads the public keys material, which could for example look like this (line breaks for are for display purposes only):</p>
<pre>
{
"keys": [
{
"kty": "RSA",
"alg": "RS256",
"use": "sig",
"kid": "b040ea9e48fec8dfd6a8859b07553dee18f19636",
"n": "zewQFS4tqHaofLLOTfliLO3gb1WnmjMYrPlVHPNdJc7WTVO5iuSVV1j5bYH0IvuoikdnBUzV0hjZiEg
OQVETlCLtXNbi7R54NjaUOSuSBFclNtf8mMXqyB3lz7hfDUPPctdXeOsl-xcfUAvqyVkfEw9FuitB0fsP3zoq
OEWa_7Kg8F7clSsz_g0fydT63qa1RyOraoF4SvisjyUWNVPsNmSCznQ1dd64y9HbX1ywkbtfqIzEcX--8ToGo
V9dgBB5VJCGem89TkBv25LzdLIoHgy0YfyXOsmPMf2cDr6eZSiZl53TjL2O8VzMF3J5T7_sFkyruGDf1GoK3a
lNT5D4YQ",
"e": "AQAB"
},
{
"kty": "RSA",
"alg": "RS256",
"use": "sig",
"kid": "fc33f33a95ce227b9956398788a49ca83bea7bf5",
"n": "qMW-G5XetV6bfJ4i6yWLLukttyLAoT3Fw3qz6sqqwRnvuS_StqAnVs7A5fWavcR3_AZimy1fJf9Gz9w
GS7xtAy_tClHUq3O8Mdixjifl3y0wcIEQpyrAc248ffiha_1YPQWzJvny03H8Pr2ZgOzJlc03A1T9We6z0-R9
zhL-wXKSpmbv-ZqbCPw7kWLUmb7OpOKPMxOyWMXHIzDEkJLXIATbekOGaltFrgJVjdXihQdYGD5vVtfJQEw2n
B_k_CPjRmMxixhsuNk3s_3V02CdcZZul_Fs4q3uvEk6iXZQviBmPztGR2fpPJ1RlhnvP4jUl8bVi7mA5_Mpft
c41tTUJQ",
"e": "AQAB"
}
]
}
</pre>
<p>Note: the right key applicable for the particular migration data JWT is identified by a key id represented by the claim "kid".</p>
<p id="rfc.section.4.p.9">If the signature has been validated successfully, the RP checks, whether it can find an existing user account in its database using the combination of iss and sub obtained from the porting data JWT. In the case of the example above, this would be the the issuer "https://op.mno1.com" and the sub "45445454".</p>
<p id="rfc.section.4.p.10">If there is a match, the RP changes the corresponding database values to the values of the claims iss and sub of the actual id token. In the example, the respective values would be "https://op.mno2.com" and "676887676767".</p>
<p id="rfc.section.4.p.11">After this step, the account of the actual user has effectively been migrated to the new OP. If the same user logs in to the same RP again, the RP would not consider the porting data again because it would sucessfully lookup the local user account using the iss and sub provided by the new OP.</p>
<h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a href="#security_considerations" id="security_considerations">Security Considerations</a></h1>
<p id="rfc.section.5.p.1">TBD </p>
<h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a href="#privacy_considerations" id="privacy_considerations">Privacy Considerations</a></h1>
<p id="rfc.section.6.p.1">TBD </p>
<h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a href="#IANA" id="IANA">IANA Considerations</a></h1>
<p id="rfc.section.7.p.1">TBD</p>
<h1 id="rfc.references"><a href="#rfc.references">8.</a> References</h1>
<h1 id="rfc.references.1"><a href="#rfc.references.1">8.1.</a> Normative References</h1>
<table>
<tbody>
<tr>
<td class="reference">
<b id="I-D.jones-oauth-amr-values">[I-D.jones-oauth-amr-values]</b>
</td>
<td class="top"><a>Jones, M.</a>, <a>Hunt, P.</a> and <a>A. Nadalin</a>, "<a href="http://tools.ietf.org/html/draft-jones-oauth-amr-values-05">Authentication Method Reference Values</a>", Internet-Draft draft-jones-oauth-amr-values-05, February 2016.</td>
</tr>
<tr>
<td class="reference">
<b id="OpenID.Core">[OpenID.Core]</b>
</td>
<td class="top"><a title="Nomura Research Institute, Ltd.">Sakimura, N.</a>, <a title="Ping Identity">Bradley, J.</a>, <a title="Microsoft">Jones, M.</a>, <a title="Google">de Medeiros, B.</a>, <a title="Salesforce">Mortimore, C.</a> and <a title="Illumila">E. Jay</a>, "<a>OpenID Connect Core 1.0</a>", December 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="OpenID.Discovery">[OpenID.Discovery]</b>
</td>
<td class="top"><a title="Nomura Research Institute, Ltd.">Sakimura, N.</a>, <a title="Ping Identity">Bradley, J.</a>, <a title="Microsoft">Jones, M.</a> and <a title="Illumila">E. Jay</a>, "<a href="http://openid.net/specs/openid-connect-discovery-1_0.html">OpenID Connect Discovery 1.0</a>", August 2015.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC2119">[RFC2119]</b>
</td>
<td class="top"><a>Bradner, S.</a>, "<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC6711">[RFC6711]</b>
</td>
<td class="top"><a>Johansson, L.</a>, "<a href="http://tools.ietf.org/html/rfc6711">An IANA Registry for Level of Assurance (LoA) Profiles</a>", RFC 6711, DOI 10.17487/RFC6711, August 2012.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC7517">[RFC7517]</b>
</td>
<td class="top"><a>Jones, M.</a>, "<a href="http://tools.ietf.org/html/rfc7517">JSON Web Key (JWK)</a>", RFC 7517, DOI 10.17487/RFC7517, May 2015.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC7519">[RFC7519]</b>
</td>
<td class="top"><a>Jones, M.</a>, <a>Bradley, J.</a> and <a>N. Sakimura</a>, "<a href="http://tools.ietf.org/html/rfc7519">JSON Web Token (JWT)</a>", RFC 7519, DOI 10.17487/RFC7519, May 2015.</td>
</tr>
</tbody>
</table>
<h1 id="rfc.references.2"><a href="#rfc.references.2">8.2.</a> Informative References</h1>
<table>
<tbody>
<tr>
<td class="reference">
<b id="E.164">[E.164]</b>
</td>
<td class="top"><a title="ITU-T">N., </a>, "<a>Recommendation ITU-T E.164</a>", November 2010.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC2246">[RFC2246]</b>
</td>
<td class="top"><a>Dierks, T.</a> and <a>C. Allen</a>, "<a href="http://tools.ietf.org/html/rfc2246">The TLS Protocol Version 1.0</a>", RFC 2246, DOI 10.17487/RFC2246, January 1999.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC5246">[RFC5246]</b>
</td>
<td class="top"><a>Dierks, T.</a> and <a>E. Rescorla</a>, "<a href="http://tools.ietf.org/html/rfc5246">The Transport Layer Security (TLS) Protocol Version 1.2</a>", RFC 5246, DOI 10.17487/RFC5246, August 2008.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC6749">[RFC6749]</b>
</td>
<td class="top"><a>Hardt, D.</a>, "<a href="http://tools.ietf.org/html/rfc6749">The OAuth 2.0 Authorization Framework</a>", RFC 6749, DOI 10.17487/RFC6749, October 2012.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC6750">[RFC6750]</b>
</td>
<td class="top"><a>Jones, M.</a> and <a>D. Hardt</a>, "<a href="http://tools.ietf.org/html/rfc6750">The OAuth 2.0 Authorization Framework: Bearer Token Usage</a>", RFC 6750, DOI 10.17487/RFC6750, October 2012.</td>
</tr>
</tbody>
</table>
<h1 id="rfc.appendix.A"><a href="#rfc.appendix.A">Appendix A.</a> <a href="#Acknowledgements" id="Acknowledgements">Acknowledgements</a></h1>
<p id="rfc.section.A.p.1">The following have contributed to the development of this specification.</p>
<p/>
<ul class="empty">
<li>Jörg Connotte (j.connotte@telekom.de), Deutsche Telekom</li>
</ul>
<p> </p>
<h1 id="rfc.appendix.B"><a href="#rfc.appendix.B">Appendix B.</a> <a href="#Notices" id="Notices">Notices</a></h1>
<p id="rfc.section.B.p.1">Copyright (c) 2015 The OpenID Foundation.</p>
<p id="rfc.section.B.p.2">The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF. </p>
<p id="rfc.section.B.p.3">The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification. </p>
<h1 id="rfc.appendix.C"><a href="#rfc.appendix.C">Appendix C.</a> <a href="#History" id="History">Document History</a></h1>
<p id="rfc.section.C.p.1">[[ To be removed from the final specification ]]</p>
<p id="rfc.section.C.p.2">-00 </p>
<ul>
<li>Initial draft</li>
</ul>
<p> </p>
<h1 id="rfc.authors">
<a href="#rfc.authors">Author's Address</a>
</h1>
<div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Torsten Lodderstedt</span>
<span class="n hidden">
<span class="family-name">Lodderstedt</span>
</span>
</span>
<span class="org vcardline">Deutsche Telekom AG</span>
<span class="adr">
<span class="vcardline">
<span class="locality"></span>
<span class="region"></span>
<span class="code"></span>
</span>
<span class="country-name vcardline"></span>
</span>
<span class="vcardline">EMail: <a href="mailto:t.lodderstedt@telekom.de">t.lodderstedt@telekom.de</a></span>
</address>
</div>
</body>
</html>