<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Calibri" size="2"><span style="font-size:11pt;">
<div>Dear all,</div>
<div>Please find below the preliminary notes of our call. Please let me know of any error or missing element.</div>
<div> </div>
<div><u>Participants:</u></div>
<div>Gonzalo Fernandez, Telefonica</div>
<div>Torsten Lodderstedt, Deutsche Telekom</div>
<div>Jörg Connotte, Deutsche Telekom</div>
<div>John Bradley, Ping Identity</div>
<div>Philippe Clément, Orange</div>
<div>Björn Hjelm</div>
<div> </div>
<div><u>Agenda:</u></div>
<ol style="margin:0;padding-left:36pt;">
<li>Document status</li><li>Basic assumptions for registration (Björn)</li><li>Sub claim persistence in case of portability</li></ol>
<div> </div>
<div><u>Discussions</u><u>:</u></div>
<ol style="margin:0;padding-left:36pt;">
<li><b>Document status</b></li></ol>
<div style="text-indent:35.4pt;">Discovery specs: Work with AC team still on track (John).</div>
<div style="text-indent:35.4pt;">Torsten remarks will be introduced and structure of the doc rearranged</div>
<ul style="margin:0;padding-left:54pt;">
<li>next version of the document to be provided by next week</li></ul>
<div> </div>
<ol start="2" style="margin:0;padding-left:36pt;">
<li><b>Basic assumptions for registration (Björn)</b></li></ol>
<ol type="a" style="margin:0;padding-left:72pt;">
<li><i>Trustworthiness of an RP</i></li></ol>
<div style="padding-left:54pt;">This trustworthiness can be done at 2 different phases, first in enrolment, second in the time of RP request</div>
<div style="padding-left:54pt;">It would be difficult to align all operators on the same rules, as probably legal and contractual conditions will differ from an operator to another.</div>
<div style="padding-left:54pt;">Remains the fact that a serving operator is different of a developer operator carrying the contract. More than this, in the European legal framework, an operator could be responsible for usage that an RP made of user data, without
carrying the contractual/legal relation.</div>
<ol type="a" start="2" style="margin:0;padding-left:72pt;">
<li><i>How to block an RP</i></li></ol>
<div style="padding-left:54pt;">An IdP has the ability to reject a RP request. The question relying on how the serving operator knows that this RP has to be blocked is OOS.</div>
<ol type="a" start="3" style="margin:0;padding-left:72pt;">
<li><i>Claims to be used in the software statement</i></li></ol>
<div style="padding-left:54pt;">List to be defined and discussed. Some examples: Identifier, redirect URI, asymmetric or public keys… </div>
<div style="padding-left:54pt;"> </div>
<ul style="margin:0;padding-left:72pt;">
<li>Björn to write a first draft of the document and insert remaining questions directly inside, to be discussed on the mailing list</li></ul>
<div style="padding-left:54pt;"> </div>
<ol start="3" style="margin:0;padding-left:36pt;">
<li><b>“</b><b>Sub</b><b>”</b><b> claim persistence in case of portability</b><b> (Gonzalo)</b></li></ol>
<div style="padding-left:18pt;">Main concern exposed by Gonzalo: when a user having an account on an RP churns from an operator to another, the sub (identifying the subject=user) towards the RP changes, due to the fact that it’s another operator to authenticate
user, this second operator having a different way to produce the sub. </div>
<div style="padding-left:18pt;">This will lead for the RP to an impossibility to link the new sub (provided by operator2) to the former sub (provided by operator1)</div>
<div style="padding-left:18pt;"> </div>
<div style="padding-left:18pt;">First level of answer is that this concern should be endorsed by operators. </div>
<div style="padding-left:18pt;">Remark: the former sub at operator1 can continue to exist and be provided to RP unless account management. </div>
<div style="padding-left:18pt;"> </div>
<div style="padding-left:18pt;">The risk to have the same reference for 2 different users at an RP doesn’t exist in OpenID Connect, since the tuple sub-issuer is unique.</div>
<div style="padding-left:18pt;"> </div>
<div style="padding-left:18pt;">A strong advice for an operator: to have an unchanging identifier (sub) for a user attached to the account, and not dependent of any dynamic user information (like MSISDN)</div>
<div style="padding-left:18pt;"> </div>
<div style="padding-left:18pt;"> </div>
<div>Kind regards,</div>
<div>Philippe</div>
<div> </div>
</span></font>
<PRE>_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
</PRE></body>
</html>