Subject: [VoT] Trust Frameworks: The anchor point of vectors of trust

From: Justin Richer <[email-masked]>
Date: Wed, 03 Jun 2015 09:34:41 -0400

As I’ve been working through the VoT concept more recently, it’s becoming clearer to me that the vectors themselves always need to be anchored in the context of some kind of trust framework agreement in order for them to make any sense at all. Now, this could be something as simple as “I’m an RP that’s been configured to trust this particular IdP no matter what it says”, or it could be something much more complex, like what the folks at GTRI have been working on for years now. [1]

In the original strawman, we proposed that there would be a “trustmark” discovery component that would allow the RP to do some processing on the request and make some reasonable decisions as to what to do with the vector information. After digging into this more, and talking with a number of people about this, I think we can take that a step further. I’m proposing that we define the values of the components in the context of trust frameworks, with a VoT IETF document itself acting as a “reasonable default” definition of these values that other trust frameworks can use.

One of the reasons that I’m looking to this approach is that there have been and will continue to be a lot of contentious arguments about the contents of these vector components. There are bound to be many context-sensitive and implementation-specific details that go into defining whether or not, for instance, a shared password of a particular entropy value qualifies as “C2" or not.

So does this mean we’re punting on core functionality and pushing it off to a nebulous “trust framework” definition? What does the VoT draft itself bring to the table, then? I think that it brings a few very valuable things:

  - A set of well-defined component categories (proofing, credentialing, assertion)
  - A default (example?) set of elements within those categories
  - A way of combining components losslessly into a single vector value (the losslessness is very important!!)
  - A way of communicating vectors across the internet in an authentication transaction
  - A way of tying the expression of a particular vector in an authentication transaction’s context to a specific trust framework/trustmark definition.

It also gives us a chance to ground the trustmark work in a real, modern identity protocol context. I think there’s been a lot of good work done here, and it needs to be expressed in a way that RPs can make sense of it, especially in light of a dynamic world. Take, for example, a user signing into an RP with an IdP that the RP has never heard of before. This is very possible with protocols like OpenID Connect, on a technology level, but it doesn’t give the RP much hope in establishing a trust relationship beyond the basic “you’re probably the server I talked to last time”. But what if the IdP is assessed by a trust framework that the RP knows about? What if the RP can programmatically process the information that the trust framework provides about the IdP?

When properly applied, this combination would give us (I believe) the hooks necessary for an RP to drill down into details about specific attributes, if desired. I strongly believe that we don’t want to chuck a ton of attributes and metadata about those attributes (and metadata about the metadata, ad nauseum) along with every authentication transaction. But I do think there’s some value in having that available through clear process grounded in the vector itself.

  — Justin

[1]https://trustmark.gtri.gatech.edu/

---

From: "Bucci, Debbie (OS/ONC)" <[email-masked]>
Date: Wed, 3 Jun 2015 15:43:02 +0000

+1

Curious .... Does the GTRI work need to be vetted or at lest recognized by IETF ?

Sent from my iPhone

> On Jun 3, 2015, at 9:34 AM, Justin Richer <[email-masked]> wrote:
> 
> _______________________________________________
> vot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vot