[Openid-specs-heart] Vectors of Trust and the Binding Ceremony

[Debbie Bucci]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150511/8823d1c2/attachment-0001.html>