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

Tue May 12 15:46:37 UTC 2015

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.

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.

On Tue, May 12, 2015 at 7:51 AM, Maxwell, Jeremy (OS/OCPO) <
Jeremy.Maxwell at hhs.gov> wrote:

>  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 *more *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?
>
>
>
>
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Eve Maler
> *Sent:* Monday, May 11, 2015 8:12 PM
> *To:* Justin Richer
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Vectors of Trust and the Binding
> Ceremony
>
>
>
> 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
>
>
>
> _______________________________________________
> 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/20150512/63b6bbb7/attachment.html>