<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)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><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-GroteskFet;
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Tele-GroteskHal;
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;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@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:1294017862;
mso-list-type:hybrid;
mso-list-template-ids:1088343956 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 l1: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, 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"><o:p> </o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">Discovery Optimization<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Under current Moderna discovery <a href="http://openid.net/wordpress-content/uploads/2014/04/draft-mobile-discovery-01.html">
http://openid.net/wordpress-content/uploads/2014/04/draft-mobile-discovery-01.html</a> a Discovery issuer endpoint will respond with an ISS url and login_hint_token. The RP now has multiple calls they will be expected to preform. (discovery issuer, discovery_ui,
discovery issuer, openid_config, Auth request). In the case of Mobile applications we wish to always optimize the number of calls, as mobile devices while capable of large through put can suffer from high latency. Furthermore in our ecosystem we have a
limited number of participants (MNO’s). Therefore we want to see if the Discovery service (Discovery issuer) would be able to help service the correct carriers openid_configuration up front.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The discovery issuer endpoint would now perform more like<o:p></o:p></p>
<p class="MsoNormal"><a href="https://discovery.com/.well-known/openid_configuration">https://discovery.com/.well-known/openid_configuration</a>
<o:p></o:p></p>
<p class="MsoNormal">and would return the correct carriers openid_configuration (and login_hint_token if appropriate).
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The discovery Service would know each MNO’s ISS. And therefore would be able to cache each MNO’s openid_configuration.
<o:p></o:p></p>
<p class="MsoNormal">RP’s would still need to extract and call each MNO’s https protected JWK_URI.
<o:p></o:p></p>
<p class="MsoNormal">Discovery service would serve openid_configurations according to caching headers, so changes to MNO openid_configurations would still propagate.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="2" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">Image discovery integration.
<o:p></o:p></li></ol>
<p class="MsoNormal">This was discussed a little in the last FAPI discussion in Boston. The carriers are investigating visual image flows to remove Phishing attack vectors. Instead of giving a Discovery UI to have a user provide the phone number (&spam pin),
the desktop browser would instead be given a visual image possibly representing a transaction id (with enough entropy). The user would then open up a mobile application to “scan” the image. The application would need to inform the Discovery service about
the Login Hint to use, and the appropriate carrier so that the RP can be informed with the login_hint, carrier, and the need for the RP to make a server initiated call (ciba) instead of a user agent initiated call.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The following is a brainstorm flow. ( I was informed that I should look at the FAPI visual flows to see what can be reused. ) Note: A major con with this flow would be the user has launched the application, but has to wait for the push
to be received to continue with the authentication request. But having the RP inform the discovery service enough OPENID connect parameters for the app to start processing would blur discovery api’s from authentication request api’s. Another Option (I believe
along FAPI direction) is for the RP to render enough data into the visual image to get the App to start processing the request as a server initiated request. Which would then trigger the POST from the MNO to the registered RP notification endpoint. We would
need to distribute a significant SDK or sample code for this level of RP integration.
<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><img border="0" width="901" height="397" style="width:9.3854in;height:4.1354in" id="Picture_x0020_1" src="cid:image001.png@01D4121A.1AF96A70"><o:p></o:p></p>
<p class="MsoNormal"><img border="0" width="901" height="780" style="width:9.3854in;height:8.125in" id="Picture_x0020_2" src="cid:image002.png@01D4121A.E6756550"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="3" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">Context parameter inbound<o:p></o:p></li></ol>
<p class="MsoNormal">A third feedback that we have considered is the need for the “context” parameter. We know at one point it was present in one of the specifications. (core?,moderna?, ciba? ) but we can’t find it anymore. MODERNA has defined the binding_message,
But the binding message carries a suggested implementation of rendering something like a pin in both the desktop, and mobile device so the user can confirm the requests are for the same transaction. The US carriers are looking for the ability to more clearly
define a text string that would be rendered to the user within just the mobile device. The context would be defined for the transaction by the RP. It would be up to the RP to define authentication or Authorization context messages for the user. Ie… “Login
to continue checking out”, or “Do you approve a transfer of $5 to xxxx”. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Context would carry a max length limitation, and would be truncated if size exceeds appropriate mobile experience.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="4" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">Context parameter outbound<o:p></o:p></li></ol>
<p class="MsoNormal">When context is requested, and the Operator includes it in the user experience, then the value would be included in the id_token. (the truncated value the user did see). GSMA has made a suggestion to look a a combined return attribute
but for now the singular context seems more appropriate. <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>
<ol style="margin-top:0in" start="5" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">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="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo2">Acknowledgment from the old mno that the user has ported Out of the old MNO<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo2">Acknowledgement from the old mno that the user has ported TO the new mno.
<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo2">Confirmation what the old MNO’s pairwise subject was.
<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo2">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>