<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>Hi Joerg,</div>
<div> </div>
<div>Some personal feedback, without answering to the question, but hope this helps:</div>
<div> </div>
<div>1- in OIDC core specs we have:</div>
<div style="text-indent:35.4pt;"><font color="#1F497D">5.5.1.1. Requesting the "acr" Claim</font></div>
<div><font color="#1F497D">If the acr Claim is requested as an Essential Claim for the ID Token with a values parameter requesting specific Authentication Context Class Reference values and the implementation supports the claims parameter, the Authorization
Server MUST return an acr Claim Value that matches one of the requested values. The Authorization Server MAY ask the End-User to re-authenticate with additional factors to meet this requirement. If this is an Essential Claim and the requirement cannot be met,
then the Authorization Server MUST treat that outcome as a failed authentication attempt. </font></div>
<div> </div>
<div>This seems to consider the acr parameter as only referencing the authentication function:</div>
<ul style="margin:0;padding-left:36pt;">
<font color="#1F497D">
<li>with a values parameter requesting specific <b>Authentication Context</b> Class Reference values</li><li>The Authorization Server MAY ask the End-User to <b>re-authenticate</b> with additional factors to meet this requirement.</li></font>
</ul>
<div> </div>
<div style="text-indent:18pt;"><font color="#1F497D">16.20. Need for Signed Requests</font></div>
<div><font color="#1F497D">In some situations, Clients might need to use signed requests to ensure that the desired request parameters are delivered to the OP without having been tampered with. For instance, the max_age and acr_values provide more assurance
about the nature of the authentication performed when delivered in signed requests. </font></div>
<a name="NeedForEncryptedRequests"></a>
<div><font face="Verdana" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>This seems to consider the acr parameter as only referencing the authentication function:</div>
<ul style="margin:0;padding-left:36pt;">
<font size="2" color="#1F497D"><span style="font-size:10.5pt;">
<li>max_age and acr_values provide more <b>assurance about the nature of the authentication</b> performed</li></span></font>
</ul>
<div> </div>
<div style="text-indent:18pt;"><font size="2" color="#1F497D"><span style="font-size:10.5pt;">2. ID Token</span></font></div>
<div><font color="#1F497D"> <font size="2"><span style="font-size:10.5pt;">acr</span></font></font></div>
<div style="padding-left:70.5pt;"><font size="2" color="#1F497D"><span style="font-size:10.5pt;">Authentication Context Class Reference. String specifying an Authentication Context Class Reference value that identifies the Authentication Context Class that
the authentication performed satisfied. The value "0" indicates the End-User authentication did not meet the requirements of ISO/IEC 29115 (International Organization for Standardization, “ISO/IEC 29115:2013 -- Information technology - Security techniques -
Entity authentication assurance framework,” March 2013.) [ISO29115] level 1. Authentication using a long-lived browser cookie, for instance, is one example where the use of "level 0" is appropriate. Authentications with level 0 SHOULD NOT be used to authorize
access to any resource of any monetary value.</span></font></div>
<div style="padding-left:70.5pt;"><font color="#1F497D"> </font></div>
<div>This seems to consider the acr parameter as only referencing the authentication function:</div>
<ul style="margin:0;padding-left:36pt;">
<font size="2" color="#1F497D"><span style="font-size:10.5pt;">
<li>Authentication Context Class Reference value that identifies the Authentication Context Class <b>that the</b><b> </b><b>authentication performed</b> satisfied</li></span></font>
</ul>
<div> </div>
<div><font size="2"><span style="font-size:10.5pt;">2- In ITU-T Recommendation X.1254 doc we have:</span></font></div>
<div><a href="https://www.oasis-open.org/committees/download.php/44751/285-17Attach1.pdf"><font face="Verdana" size="3" color="blue"><span style="font-size:12pt;"><u>https://www.oasis-open.org/committees/download.php/44751/285-17Attach1.pdf</u></span></font></a></div>
<div> </div>
<div><font size="2" color="#1F497D"><span style="font-size:10.5pt;">Assurance within this Recommendation | International Standard refers to the confidence placed in all of the processes, management activities, and technologies used to establish and manage the
identity of an entity for use in authentication transactions.</span></font></div>
<div> </div>
<div><img src="cid:3BB68D6C10BC0A4889FB56CDA8BFAB40@adroot.infra.ftgroup"><font face="Verdana" size="3"><span style="font-size:12pt;"> </span></font></div>
<div> </div>
<div> </div>
<div><font size="2"><span style="font-size:10.5pt;">Question: are we allowed to consider that OpenID Connect specifications, through the acr parameter, consider solely the Entity authentication phase (3rd part of the above sheet), or not ?</span></font></div>
<div> </div>
<div><font size="2"><span style="font-size:10.5pt;">Kind regards,</span></font></div>
<div><font size="2"><span style="font-size:10.5pt;">Philippe</span></font></div>
<div> </div>
<div><font face="Verdana" size="3"><span style="font-size:12pt;"><img width="83" height="41" src="rtfimage://"></span></font></div>
<div> </div>
<div> </div>
<div>-----Message d'origine-----<br>
De : 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>] De la part de Connotte, Joerg<br>
Envoyé : dimanche 8 février 2015 20:52<br>
À : openid-specs-mobile-profile@lists.openid.net<br>
Objet : [Openid-specs-mobile-profile] level of assurance as acr_values in mobile profile</div>
<div> </div>
<div>Dear all,</div>
<div> </div>
<div>I wanted to share some considerations we discussed about how to address the task of specify standard values for acr in the Mobile Profile.</div>
<div> </div>
<div>Making a distinction between identity and credential of an entity:</div>
<div>The levels of assurance as defined in ISO29115 mix up the assurance about the identity of an entity and assurance about the credentials of an entity used during authentication.</div>
<div>However those two aspects of an entity are altogether different and basically independent of each other.</div>
<div> </div>
<div>Identity of an entity is information about certain (personal) data of an entity. In case the entity in question is a real person examples for those are: given name, last name, birthday, address etc.</div>
<div>Thus assurance about identity concern itself with answers to the questions how well the information about this identity is validated. I other words how much effort was taken to ensure the correctness of the data. During authentication this information
is not re-validated.</div>
<div> </div>
<div>Credentials:</div>
<div>Credentials are secrets in possesion of and in some cases controlled by an entity which are used to validate an authentication. </div>
<div>Typical credentials are username/password, mobile network, fingerprint etc. </div>
<div>Assurance about credentials concerns itself with the trustworthiness of the mechanisms actually used to protect those credentials.</div>
<div> </div>
<div>Implications:</div>
<div>Assurance that an entity is the same over consecutive authentication processes can rely solely on the assurance of the protection of the credentials of this entity. It is not necessary to know anything about the identity of the entity.</div>
<div> </div>
<div>It is theoretically possible to have a high level of assurance about the correctness of certain identity information about an entity without a high level of assurance about the correctness of the credentials of the same entity.</div>
<div>Moreover validating identity information about an entity may be difficult whereas providing a trustworthy set of credentials is relatively easy.</div>
<div> </div>
<div>Proposition for Mobile Profile:</div>
<div>The definition of a separate set of acr values for 'credential assurance' and 'identity assurance' seems to be a useful thing to consider. For most use cases discussed in the Mobile Connect project secure authentication without exposing any identity data
execpt a unique identifier is sufficient.</div>
<div> </div>
<div>What do you think?</div>
<div> </div>
<div>Kind Regards</div>
<div>Jörg Connotte </div>
<div> </div>
<div> </div>
<div>DEUTSCHE TELEKOM AG</div>
<div>Products & Innovation</div>
<div>Jörg Connotte</div>
<div>Customer Platforms</div>
<div>T-Online-Allee 1, 64295 Darmstadt</div>
<div>+49 6151 680-7288 (Tel.)</div>
<div>+49 151 184-15517 (Mobil)</div>
<div>E-Mail: <a href="mailto:j.connotte@telekom.de">j.connotte@telekom.de</a></div>
<div><a href="http://www.telekom.com">www.telekom.com</a></div>
<div> </div>
<div>LIFE IS FOR SHARING. </div>
<div> </div>
<div>You can find the obligatory information on <a href="http://www.telekom.com/compulsory-statement">www.telekom.com/compulsory-statement</a></div>
<div> </div>
<div>BIG CHANGES START SMALL - CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL.</div>
<div> </div>
<div>_______________________________________________</div>
<div>Openid-specs-mobile-profile mailing list <a href="mailto:Openid-specs-mobile-profile@lists.openid.net">Openid-specs-mobile-profile@lists.openid.net</a></div>
<div><a href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</a></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>