<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 12 (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";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.E-MailFormatvorlage17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1134104017;
mso-list-type:hybrid;
mso-list-template-ids:-196694814 67567633 67567641 67567643 67567631 67567641 67567643 67567631 67567641 67567643;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1
{mso-list-id:1638411546;
mso-list-type:hybrid;
mso-list-template-ids:-852713640 67567637 67567641 67567643 67567631 67567641 67567643 67567631 67567641 67567643;}
@list l1:level1
{mso-level-text:"\(%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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="DE" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi all,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">during the working session at IIW it became apparent that we don’t have a consent on the way client credentials are managed for native apps in the context of the mobile profile. As this an important design consideration,
which will drive not only the registration spec but also considerations with respect to signature algorithms and so on, I would like to come to a consensus on that topic soon.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">There are basically two options:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span lang="EN-US"><span style="mso-list:Ignore">1)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US">All instances of a native app (== the software package) share the same identity. This typically means, the app is registered as a so-called public client with the AS/OP and only gets issued a client_id. In the
context of the mobile profile, I would assume the developer registers with a developer portal and gets issued distinct client_ids per MNO (a pair of issuer and client_id). At runtime, the app can decide based on the outcome of the discovery process which client_id
to use for the respective MNO.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span lang="EN-US"><span style="mso-list:Ignore">2)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US">Every instance of a native app on a device is registered with the MNO. This would typically happen when the user uses the login with a certain MNO on this device for the first time. So the app first would discover
the MNO and determine whether it already is in possession of client credentials for this particular MNO (based on its Issuer). If not, it would send a registration request to the MNO.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I see the following pros and cons:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Option (1) is established practice (except the fact an app managing several client ids for different OPs). So developers know how to work that way. Software statements could be used to automate the way client ids are
obtain in the deployment process. But there are other ways as well.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Option (2) is a new approach. It has the advantage to provide every instance with a distinct credential, which allows to recognize and authenticate this instance later on. It could be used to prevent authz code theft
on the device, something we already have SPOP for (<a href="http://tools.ietf.org/html/draft-ietf-oauth-spop-10">http://tools.ietf.org/html/draft-ietf-oauth-spop-10</a> - sorry John, forgot the new acronym). Do you see other advantages? On the other hand,
this option would require the OP to implement credential management for potentially a lot of client instances. This will be a challenge with respect to state management on the OP’s side.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Please comment on this topic.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Thanks in Advance,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Torsten.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal">DEUTSCHE TELEKOM AG<o:p></o:p></p>
<p class="MsoNormal">Products & Innovation<o:p></o:p></p>
<p class="MsoNormal">Dr.-Ing. <span lang="EN-US">Torsten Lodderstedt<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Head of Development<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Customer Platforms<o:p></o:p></span></p>
<p class="MsoNormal">T-Online Allee 1, 64295 Darmstadt<o:p></o:p></p>
<p class="MsoNormal">+49 6151 680 7038 (Tel.)<o:p></o:p></p>
<p class="MsoNormal"><span lang="IT">E-Mail: </span><a href="mailto:t.lodderstedt@telekom.de"><span lang="IT" style="color:blue">t.lodderstedt@telekom.de</span></a><span lang="IT"><o:p></o:p></span></p>
<p class="MsoNormal"><a href="http://www.telekom.com"><span style="color:blue">www.telekom.com</span></a> <br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">ERLEBEN, WAS VERBINDET. <br>
<br>
<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Arial","sans-serif"">Die gesetzlichen Pflichtangaben finden Sie unter:
<br>
<a href="http://www.telekom.com/pflichtangaben"><span style="color:blue">www.telekom.com/pflichtangaben</span></a></span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>