<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=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","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
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.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;}
--></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="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Wholeheartedly agree that individuals should be given options and the choice to select credentials that work for them. At first I thought we were saying social
credentials could not be on the list of choices.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Sarah Squire [mailto:sarah@engageidentity.com]
<br>
<b>Sent:</b> Tuesday, May 12, 2015 11:47 AM<br>
<b>To:</b> Maxwell, Jeremy (OS/OCPO)<br>
<b>Cc:</b> Eve Maler; Justin Richer; openid-specs-heart@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-heart] Vectors of Trust and the Binding Ceremony<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">The problem is not that social credentials are insecure. The problem is that users often don't trust them. I think the idea here, as in NSTIC in general, is that users should be able to use their chosen Identity Provider (IdP). This creates
a market for IdPs that incentivizes them to get better.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">That said, because users don't pay for social IdPs, they are in a different class legally. Social IdPs are much more loosely regulated in terms of notification and consent than an IdP with a financial relationship with the user, like a
bank, university, or employer.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Tue, May 12, 2015 at 7:51 AM, Maxwell, Jeremy (OS/OCPO) <<a href="mailto:Jeremy.Maxwell@hhs.gov" target="_blank">Jeremy.Maxwell@hhs.gov</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Why is a social credential a bad credential for authenticating to a patient portal? For many individuals,
the private details of their social accounts may be held <i>more </i>privately than their health records. There are a few celebrities that wish their iCloud accounts were more secure. Gmail allows for 2fx authentication if users want it. What about if/when
I can sign into my Microsoft Live account using facial recognition in Windows 10? Assume there existed a strong identity proofing method that is able to bind my social credential to my identity in the portal. Would allowing individuals to use a social credential
(for authentication to the portal) after this point be insecure?</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">openid-specs-heart-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>Eve Maler<br>
<b>Sent:</b> Monday, May 11, 2015 8:12 PM<br>
<b>To:</b> Justin Richer<br>
<b>Cc:</b> <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-heart] Vectors of Trust and the Binding Ceremony</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The VOT work is really exciting, and Justin's description of it -- and the vulnerabilities lurking in locally managed accounts that often go unremarked -- is very helpful and on-point.
<span style="background:yellow">Though "social" identities are perhaps not the best choices for logging in to patient portals</span>, the social-style login pattern works perfectly well, and need not increase risk.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">BTW, if folks haven't noticed, there's a new OpenID Foundation work group called "<a href="http://openid.net/wg/risc/" target="_blank">RISC</a>" (Risk and Incident Sharing Coordination)
to enable event notifications around compromised accounts, so that, e.g., a <a href="http://gmail.com" target="_blank">
gmail.com</a> confirmation loop compromise won't infect additional accounts. I believe that efforts like this will ultimately have more powerful impacts than all the password policies in the world. :-)<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br clear="all">
<o:p></o:p></p>
<div>
<div>
<div>
<div>
<div>
<p><b>Eve Maler<br>
</b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>
Cell <a href="tel:%2B1%20425.345.6756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br>
Join our <a href="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a> community!<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Mon, May 11, 2015 at 4:30 PM, Justin Richer <<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Swap 4 and 6 and it still works, but fed is simpler for Alice so she'll probably stop there.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On 5/11/2015 7:27 PM, Debbie Bucci wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">How will that simplify the current Federation process - maybe I'm asking how is the actual binding to the system performed:<br>
<br>
Current process often adds additional steps but you can get there <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
1. Alice shows up at her doc’s<br>
2. Alice shows her ID and insurance card, these get verified<br>
3. A record gets created for Alice in the system<br>
4. The system issues Alice a new username and password - or one time link (likely bounced through her external personal email address from it-doesn’t-matter-where)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"> 5. Alice logs in
<br>
6. Alice now given the option to use alternative (in person) with her personal digital identity (from it-doesn’t-matter-where as long as it registered in system's the metadata) and this is bound to her account (will assume via some session context
switch )<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Mon, May 11, 2015 at 6:11 PM, Justin Richer <<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt">The Vectors of Trust work that I mentioned on today’s call is, at its heart, an effort to take the different aspects of a “level of assurance” as defined in MB-0404 and SP-800-63 and
break them apart into individual components so that they can be considered separately. What’s driving this is that one of the biggest problems in the wild of 800-63 is that it conflates the strength of the credential with the strength of the proofing (among
other things), such that it doesn’t make sense within that context to have an anonymous credential with a high level of assurance. This is probably fine if you’re the government doing background checks on people before you hand out PKI cards to its employees
and contractors, but not only are there other use cases out there (to which 800-63 has time and again be erroneously applied) but also technologies have advanced significantly in the last decade.<br>
<br>
So in VoT we propose to break out identity proofing, credential strength/binding, and assertion strength. These names and categories are still up in the air, but the concept is that there are different parts that need to be communicated separately. So instead
of something coming across the wire as “LOA2”, it could come across as “P1.C3.A2”, which translates to “proofed at level 1, credentialed at level 3, asserted at level 2”. Now the question is: what does the RP do with this information? Well that depends on
who’s claiming it, and that’s where the trust framework and trustmark efforts come into play. These will serve as the anchor for the IdP to assert any particular vector, and the trust framework itself will let the RP know what it can do with that information.<br>
<br>
The list is here and the archives are available online:<br>
<br>
<a href="https://www.ietf.org/mailman/listinfo/vot" target="_blank">https://www.ietf.org/mailman/listinfo/vot</a><br>
<br>
And to pull the curtain back a bit, I’m currently working on an update to my initial proposal now, with intention that it be discussed at the next IETF meeting in Prague. It’s not (yet) an IETF working group, so we’re still figuring out exactly where this is
going to ultimately land.<br>
<br>
<br>
<br>
As to the identity binding ceremony, it really fits in with what I’m discussing above: the proofing that is done at Alice’s IdP doesn’t really matter if Alice is doing some higher value proofing at her doctor’s office already. So what we’ve got today is something
like:<br>
<br>
1. Alice shows up at her doc’s<br>
2. Alice shows her ID and insurance card, these get verified<br>
3. A record gets created for Alice in the system<br>
4. The system issues Alice a new username and password (likely bounced through her external personal email address from it-doesn’t-matter-where)<br>
<br>
What I’m suggesting here is that we can use the identity federation technology to replace the last part of this, to:<br>
<br>
1. Alice shows up at her doc’s<br>
2. Alice shows her ID and insurance card, these get verified<br>
3. A record gets created for Alice in the system<br>
4. Alice logs in (in person) with her personal digital identity (from it-doesn’t-matter-where) and this is bound to her account<br>
<br>
<br>
Alice’s proofing is done in person so the IdP doesn’t need to do that. It’s nearly guaranteed to be a better security profile than giving Alice another password to manage, for many reasons I won’t enumerate on here right now because the internet would run out
of bits for my email. It’s going to be a much better user experience for Alice, who can use a familiar account to manage things. So are Alice’s attributes worthless? Hardly! The medical system is still going to want things like Alice’s display name and email
address, for its own uses, and the IdP can provide these as inputs, with Alice making sure they’re what she wants in the system. Otherwise, remember, Alice is just going to be filling out the “sign up” form herself anyway. The important thing is that the digital
identity (the iss/sub pairing in OIDC) is tied to a specific set of rights that include a specific medical record (or set of records).<br>
<br>
<br>
Now some people get all scared about talking to external IdPs, but it’s important, I believe, to point out that in the first case, Alice is probably going to do some kind of reset password link through her email address. Which means that anyone who manages
to 0wn Alice’s gmail account can now reset her password and log into her medical record. This turns out to be the same security profile as the second case, except that now Alice’s IdP can *also* look for suspicious activity of someone using her account at
her medical office. The explicit account binding ceremony lets both sides see clearly what’s up.<br>
<br>
<br>
As such, what I’m suggesting here (and in the VA-based “Steve” use case on the wiki) is that identity federation really does buy us a lot, and notions of “Alice needs a High LoA” really don’t make sense when you pull things apart. What we need to continue doing,
in HEART, is to break things down into their components and re-build them into the right systems for the world. The use cases can help guide us to what those pieces are, but remember that they don’t dictate what the systems will be.<br>
<span style="color:#888888"><br>
— Justin<br>
</span><br>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><br>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>