Re: [VoT] Vectors of Trust: A Strawman

["Cantor, Scott" <[e-mail]>]

On 10/2/14, 5:10 PM, "Richer, Justin P." <[e-mail]> wrote:

>I'm going to propose 4 here, all of them linear scales. As a side note,
>it's a question whether all of these are even linear scales, but I think
>it's important that we define comparison metrics on each vector element
>as well as the overall values.

As I said in another note, I'm not sure any of them are really linear or
that reducing them to that is an accurate way of communicating anything
useful, but I'm also not sure there's an alternative that's palatable.
It's a question of how lossy it's possible to be and not lose the signal I
guess.

>Identity proofing:
>
>This covers how sure the IdP is of various attributes about the user on
>the way in, and how much they're willing to vouch for those attributes.

Are we proposing that this is intrinsically per-attribute? Something that
people have been dancing around for years, really.

As others mentioned, I think it's even better to avoid the word identity
entirely. There is no well-defined notion of "physical identity" in the
digital space, only poorly expressed approximations. I think there are
only attributes.

>Credential strength:
>This covers how strongly bound the primary credential is to an individual
>presenter, and how easily spoofed or stolen it is.

Maybe the word "and" in that sentence demonstrates that there are multiple
vectors in play there.

>Assertion presentation:
>
>This covers how much the federation protocol leaks information over the
>network to various parties, and how much of that information could be
>tampered in transit without the RP noticing.
>
>0: no protection / leaky
>1: signed & verifiable through browser
>2: signed & verifiable through back channel
>3: target-encrypted to RP's own key

I think somebody else noted those are themselves orthogonal.
Confidentality and integrity/strength are tunable independently.


>Operational management:
>
>This covers a variety of information about the identity provider and its
>host organization. What's the OpSec policy of the IdP? Is there disaster
>recovery in place? How mature is the hosting organization? What kind of
>incident response can be expected?
> How strongly bound is a particular attribute to a particular credential
>[though maybe this fits under identity proofing]? You'll note that
>already this feels a lot less linear and a lot less defined than the
>other three.

It's much more well defined IMHO, but decidedly less linear.

>Finally, I think we need to think about and discuss the notion of the
>assessment and trustmarks that would be powering the trust in all of
>these values. After all, if they're just self-asserted by the IdP, that
>doesn't really help anyone. However, if we had a discovery mechanism
>whereby a trustmark provider would be able to host a machine-readable
>definition of what vectors a particular IdP has been proven to be able to
>claim for any transaction, I think we've got a good leg up on the problem.

Yes, we've been using SAML metadata to do these kinds of things for a
while now.

-- Scott