[Openid-specs-heart] Vectors of Trust and the Binding Ceremony
Eve Maler
eve.maler at forgerock.com
Tue May 12 00:11:51 UTC 2015
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.
BTW, if folks haven't noticed, there's a new OpenID Foundation work group
called "RISC <http://openid.net/wg/risc/>" (Risk and Incident Sharing
Coordination) to enable event notifications around compromised accounts, so
that, e.g., a gmail.com 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. :-)
*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!
On Mon, May 11, 2015 at 4:30 PM, Justin Richer <jricher at mit.edu> wrote:
> Swap 4 and 6 and it still works, but fed is simpler for Alice so she'll
> probably stop there.
>
>
> On 5/11/2015 7:27 PM, Debbie Bucci wrote:
>
>
> How will that simplify the current Federation process - maybe I'm asking
> how is the actual binding to the system performed:
>
> Current process often adds additional steps but you can get there
>
> 1. Alice shows up at her doc’s
> 2. Alice shows her ID and insurance card, these get verified
> 3. A record gets created for Alice in the system
> 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)
> 5. Alice logs in
> 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 )
>
>
>
>
>
>
> On Mon, May 11, 2015 at 6:11 PM, Justin Richer <jricher at mit.edu> wrote:
>
>> 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.
>>
>> 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.
>>
>> The list is here and the archives are available online:
>>
>> https://www.ietf.org/mailman/listinfo/vot
>>
>> 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.
>>
>>
>>
>> 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:
>>
>> 1. Alice shows up at her doc’s
>> 2. Alice shows her ID and insurance card, these get verified
>> 3. A record gets created for Alice in the system
>> 4. The system issues Alice a new username and password (likely
>> bounced through her external personal email address from
>> it-doesn’t-matter-where)
>>
>> What I’m suggesting here is that we can use the identity federation
>> technology to replace the last part of this, to:
>>
>> 1. Alice shows up at her doc’s
>> 2. Alice shows her ID and insurance card, these get verified
>> 3. A record gets created for Alice in the system
>> 4. Alice logs in (in person) with her personal digital identity
>> (from it-doesn’t-matter-where) and this is bound to her account
>>
>>
>> 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).
>>
>>
>> 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.
>>
>>
>> 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.
>>
>> — Justin
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150511/55782e2d/attachment.html>
More information about the Openid-specs-heart
mailing list