<div dir="ltr">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. Though "social" identities are perhaps not the best choices for logging in to patient portals, the social-style login pattern works perfectly well, and need not increase risk.<div><br></div><div>BTW, if folks haven't noticed, there's a new OpenID Foundation work group called "<a href="http://openid.net/wg/risc/">RISC</a>" (Risk and Incident Sharing Coordination) to enable event notifications around compromised accounts, so that, e.g., a <a href="http://gmail.com">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. :-)</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Join our <a href="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a> community!</p></div></div></div></div></div>
<br><div class="gmail_quote">On Mon, May 11, 2015 at 4:30 PM, Justin Richer <span dir="ltr"><<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Swap 4 and 6 and it still works, but fed is simpler for Alice so
she'll probably stop there.<div><div class="h5"><br>
<br>
<div>On 5/11/2015 7:27 PM, Debbie Bucci
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div><br>
</div>
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 <br>
</div>
<div>
<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)<br>
</div>
<div> 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 )<br>
<br>
<br>
</div>
<div><br>
</div>
<div><br>
</div>
<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, May 11, 2015 at 6:11 PM, Justin
Richer <span dir="ltr"><<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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><font color="#888888"><br>
— Justin<br>
</font></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><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
<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><br>
<br></blockquote></div><br></div>