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

Tue May 12 19:33:58 UTC 2015

I liked that Justin’s first e-mail broken this down into pieces that help me understand what he is advocating. However, at the same time opening a hundred rabbit holes to fall into☺

I have two questions to start with:

To address one misunderstanding, in the use case, Alice’s PHR supports two-factor authentication while the PCP system doesn’t; however, the PCP portal provides stronger proofing then Alice’s PHR does. Ideally Alice would want to manage everything including her credentials and profiles from her PHR.

So the question is, what are Alice’s options assuming she wants to use SSO between her PHR and the PCP portal?

·        How does OpenId Connect transmit equivalent of the VoT concept of “P1.C3.A2”?

·        Map her credentials between systems?

·        Elevate her PHR login (credentials )?

So is this possible today with OpenId/oAuth/UMA?  If so, how? If not, what is required?

Second:
While I like and generally agree with the concept that VoT is proposing, from my understanding, VoT is not a standard today; but a IETF discussion to perhaps become a standard in the future.

I guess this would open another discussion as to what credentialing/authentication standards should HEART support to support interoperability?

Bill

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Sarah Squire
Sent: Tuesday, May 12, 2015 11:47 AM
To: Maxwell, Jeremy (OS/OCPO)
Cc: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Vectors of Trust and the Binding Ceremony

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<mailto: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<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<mailto: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<http://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<tel:%2B1%20425.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<mailto: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<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

_______________________________________________
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

_______________________________________________
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/20150512/c90bee21/attachment-0001.html>