<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=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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:Tele-GroteskHal;
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Tele-GroteskFet;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:735510651;
mso-list-type:hybrid;
mso-list-template-ids:1313234136 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:1003892847;
mso-list-template-ids:-1431555070;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2
{mso-list-id:1294017862;
mso-list-type:hybrid;
mso-list-template-ids:1088343956 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">Good morning, Sorry for my delayed response, I was out on vacation.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I have added some comments inline with yours with my initials [me]<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Manger, James [mailto:James.H.Manger@team.telstra.com]
<br>
<b>Sent:</b> Tuesday, July 10, 2018 7:54 AM<br>
<b>To:</b> Engan, Michael <Michael.Engan1@T-Mobile.com>; Openid-specs-mobile-profile <openid-specs-mobile-profile@lists.openid.net><br>
<b>Subject:</b> RE: Moderna Feedback from T-Mobile: AKA for porting<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D">Hi Michael,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D">“The assertion from the old MNO” actually needs to be many assertions — one per RP — since it carries “the old MNO’s pairwise subject” (ie a RP-specific “sub”).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D">So if a user has accessed 100 RPs, then during porting the old MNO need to generate, sign and send 100 JWTs, and the new MNO need to store these. Would we need limits?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU">[me] this is already the case. If the user ports under the current moderna suggestion, then the old mno needs to generate a PORT token. In order for that PORT token to return the correct pairwise subject identified the
old MNO needs to track which RP it was issued to, and therefore issue a different PORT token for each RP the user already visited. Likewise this means the New MNO also has to know which previous RP’s the user had approved (we want this anyways so the consents
port), and store an AKA value to use for each. So the suggestion to make the PORT token a JWT does not shift the underlying needs there to track per RP. NOTE: all this would be easier IF the MNO’s don’t use pairwise Subject identifiers. In which case a
single AKA value for OLD sub would work. (still signed by some method). But our business teams have reiterated that they want MNO’s to use pairwise identifiers for each sector_url.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D">An old MNO might not know all the RPs a user has visited. It isn’t strictly necessary to record this if the per-RP pairwise sub is
<i>derived</i> whenever a login to that RP occurs. That would make it basically impossible to generate all the assertions at the porting time.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU">[me] the old MNO must capture consents. Even if the MNO generates the pairwise subject identifier with each login, the MNO has to still have a record to confirm if the user has already granted this RP access to the requested
scopes. Otherwise the user will be asked with every login/access … “user do you agree this RP can access your xxx”. Note: to support porting I know T-Mobile will need to convert our realtime generation of the pairwise subject. But this is needed
because we will also now need to support a pairwise subject login Hint. We don’t want RP’s using the phone number so if the RP is told to use the subject as the reference. Then the RP needs to be able to use the subject as the login hint, and therefore We
have to have a recorded version of each pairwise subject so we can lookup which internal user it is referencing.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D">Another disadvantage of generating all the per-RP assertions up front (at port time) is the privacy issue. The new MNO learns the user’s entire history, even if the user never intends to visit some
of the old RPs ever again.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU">[me] ok, yes I agree.. but this is 1) a biz call.. when a user ports a phone number from one carrier to another carrier will the user be able to Port their identity.. (when mno’s use pairwise that means porting all
your RP’s, consents you granted each, and the subject/token/porttoken you were known as for that RP. 2) this is also user controlled. When a new MNO wants to pull/port you they will make an authentication request to the old MNO with the “Port_data”
scope. This means the User can be shown and explicitly consent to the porting of all their data from the old carrier to the new carrier. If the user chooses they can decline consent for the port_data scope, while approving other scopes like “profile”. This
would let a user simplify onboarding to the new MNO, but RP’s will see a new Subject. (possibly with existing attributes like phone number, and email). This may cause security problems where we tell RP’s to use the subject as the reference, and the other
fields as simple data attributes.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D">Assertions that are generated at port time, but not consumed by an RP until the user next signs in to that RP (perhaps months later), means we need longer-term keys and revocation support. In contrast
to the current scheme that can operate with frequently-rotated short-term no-revocation-needed keys.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU">[me] correct. Totally agree. Which is why I suggest that an MNO generate two key pairs. One for JWT -> ID_Tokens which can be rotated frequently. And then a second Key pair JUST for signing/encrypting the PORT token(jwt/jwe)
which would rotate slowly. It could be possible that the old MNO still allows an interface that a RP could use for Port token validation in the event the port token siging key has rotated out of the jwks file. (in which case the old mno needs to keep it
internally listed for longer). But even if we don’t make the port_token a JWT, the old MNO still needs to keep in memory for a long period the method of validating that token and the data it represents, which is still the same challenge.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D">--<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D">James Manger<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-AU" style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Openid-specs-mobile-profile [<a href="mailto:openid-specs-mobile-profile-bounces@lists.openid.net">mailto:openid-specs-mobile-profile-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>Engan, Michael<br>
<b>Sent:</b> Tuesday, 3 July 2018 8:52 AM<br>
<b>To:</b> Openid-specs-mobile-profile <<a href="mailto:openid-specs-mobile-profile@lists.openid.net">openid-specs-mobile-profile@lists.openid.net</a>><br>
<b>Subject:</b> [Openid-specs-mobile-profile] Moderna Feedback from T-Mobile<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-AU"><o:p> </o:p></span></p>
<p class="MsoNormal">Good Morning, I would like to offer up some feedback conversations to the working group on the following:
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">…</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoNormal" style="mso-list:l0 level1 lfo2">AKA for Porting<o:p></o:p></li></ol>
<p class="MsoNormal">The US carriers have been discussing the AKA parameter for account porting. Ideally an ID_Token can be validated by an RP with only a cached public key for the carrier. Under the current suggestions the RP would now need to make a request
to the original carrier with any port_token to complete the validation. To go back to completely validated by the RP, we would like to see the AKA port token be something like a JWT, or JWE from the original carrier. This way the RP can validate the id_token,
and the port_token with cached jwk public keys from both the new and original MNO.
<o:p></o:p></p>
<p class="MsoNormal">The assertion from the old MNO needs to carry at least<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="mso-list:l2 level1 lfo5">Acknowledgment from the old mno that the user has ported Out of the old MNO<o:p></o:p></li><li class="MsoNormal" style="mso-list:l2 level1 lfo5">Acknowledgement from the old mno that the user has ported TO the new mno.
<o:p></o:p></li><li class="MsoNormal" style="mso-list:l2 level1 lfo5">Confirmation what the old MNO’s pairwise subject was.
<o:p></o:p></li><li class="MsoNormal" style="mso-list:l2 level1 lfo5">Possibly a date of the PORT for use in anti-fraud detection.
<o:p></o:p></li></ul>
<p class="MsoNormal">It will remain up to the RP to update their subject from the old mno Sub to the new mno’s sub once AKA port_token validation is complete.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><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-size:10.0pt;font-family:Tele-GroteskFet;color:#1F497D">Michael Engan <br>
</span><span style="font-size:9.0pt;font-family:Tele-GroteskHal;color:#1F497D">Principal Systems Architect,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:Tele-GroteskHal;color:#1F497D">Authentication, Authorization, & API security</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:Tele-GroteskHal;color:#1F497D">12920 SE 38<sup>th</sup> Street | Bellevue, WA 98006<br>
Direct 425-383-2268 | Mobile 425-443-3463</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>