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

[Justin Richer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150511/03cbb848/attachment.asc>