<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">This message is to inform the LC & TIWG that staff has received the following comments to the Bridging IMS and Internet Identity Whitepaper. <div><br></div><div><div><b>Comments</b>: </div><div>This draft Recommendation would greatly benefit from more contextual discussion regarding security and privacy considerations, particularly as they relate to identity and entity authentication, and the related ongoing activities in Standards Development Organizations, such as ITU-T and ISO-IEC JTC1. As this draft Recommendation generally relates to the sharing of identity/entity authentication from the telecommunications world to identity authentication in the internet, it is necessary to further describe how: the security perimeter is extended from entity to user, and; how the privacy considerations are maintained, not only across jurisdictional boundaries, but also as they relate to user data that may be transported from applications, to entity hardware, to telecommunications operator. Any implicit assumptions regarding these areas need to be more explicitly stated for maximum benefit of the document and its progression.</div><div><br></div><div>1)<span class="Apple-tab-span" style="white-space:pre"> </span>Security Considerations:</div><div>Lines 125-127</div><div>"users of classic telco services like voice, fax, and SMS do not need to handle and maintain passwords, since they are authenticated by the network".</div><div>Lines 400-402 </div><div>discusses operators providing "strong SIM authentication service towards originally much weaker security". </div><div>Lines 335-340</div><div>discusses the higher security and privacy protection via “the ability to ability to reuse the network embedded security mechanisms of operators for user interactions with all services inside the operator realm and across the Internet increases the level of security and privacy protection compared to what exists today. As well as enabling end-users to utilize a transaction broker brand like an operator that is trustable and that can legally be responsible for the security level involved in the transaction”</div><div><br></div><div>In the cases above where there is comparison, it would be instructive to define what is being compared, and what the assumptions are regarding a user authenticating to an entity (phone or SIM). Is the binding of the user to the entity assumed to be through the possession of the entity, via a contractual obligation, or by a secondary means of authentication? The distinction between user authentication and entity authentication is not clearly expressed in these sections, and the draft Recommendation requires further clarification.</div><div><br></div><div>Furthermore, it would be beneficial to explain how the "legal responsibility for the security level involved in the transaction" relate to the Levels of Assurance (LoA) used in NIST Special Publication 800-63 and Kantara Identity Assurance Framework (IAF) Version 2.0. Is it intended that the entity authentication described in the draft Recommendation includes an implicit identity authentication via possession, or would it be used in conjunction with a second factor such as passwords or biometrics, to authenticate for a LoA 3 transaction, as is described in NIST 800-63 and Kantara IAF? </div><div><br></div><div>2)<span class="Apple-tab-span" style="white-space:pre"> </span>Privacy Considerations</div><div>Lines 191-193 </div><div>discusses "the exported "public identity" (e.g. a unique TELURI or SIPURI) a strong privacy constraint is inherited preventing the leveraging of 3rd parties services". Presumably this is achieved through the use of persistent anonymous identifiers mapped to the real user ID, as described in lines 423-424: "During this process, the telecom operator will provide an alias instead of real user ID's (i.e. phone number)”. </div><div>Lines 559-567 </div><div>discusses using cookies to share the authentication context</div><div><br></div><div>Further description of how user data privacy is maintained throughout these and other processes in the draft Recommendation should be included. In particular, the safeguards that are used to maintain the confidentiality of the user data in rest and in transit should be included. It would also be very helpful to include a discussion of the expectations of the various stakeholders in the data flow process, such as applications running on the cell phone, the hardware itself (including SIM’s or TPM’s), and the telecommunications operators, as the data traverses the various jurisdictional and application boundaries.</div></div><div><br></div><div><div><br></div><div>I expect TIWG leadership to review and discuss these comments today at their F2F meeting in Berlin. The review period will end close of business today, July 1. If further comments arrive I will forward to LC and TIWG. </div><div><br></div><div>Cheers, </div><div>Dervla</div><div apple-content-edited="true"> <div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><span class="Apple-style-span" style="font-family: Helvetica, Verdana, Helvetica, Arial; font-size: 12px; "><div><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt; ">________________________<br></span></font><font size="2"><font face="Times New Roman"><span style="font-size: 10pt; ">Dervla O’Reilly<br>Program Manager</span></font></font></div><div><font size="2"><font face="Times New Roman"><span style="font-size: 10pt; ">Kantara Initiative</span></font></font></div><div><font size="2"><font face="Times New Roman"><span style="font-size: 10pt; ">+1 415 731 4487 business<br>+1 415 948 3650 mobile<br>+1 509 757 4487 fax<br>dervla[at]kantarainitiative[dot]org</span></font></font></div><div><font class="Apple-style-span" face="'Times New Roman'" size="3"><span class="Apple-style-span" style="font-size: 13px; "><a href="http://www.kantarainitiative.org">http://www.kantarainitiative.org</a></span></font></div></span></div></div> </div><br></div></body></html>