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

[Justin Richer]

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 
> <mailto: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
>     <mailto: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/a94b86f9/attachment.html>