Re: [VoT] Vectors of Trust: A Strawman

[Jim Fenton <[e-mail]>]

Hi Justin,

Good kickoff!

On 10/2/14 2:10 PM, Richer, Justin P. wrote:
>
> The first question is what vectors should there be? Embedded in this
> is how many there should be in the first place. Too few vectors and we
> end up with the overly-simplified and usually-misused problem that LoA
> has today. Too many vectors and we end up with an un-navigable set of
> values where everybody's niche concern is a special snowflake. We need
> to stay allergic to both cases and shoot for something "in the
> middle". In particular, my own personal gut instinct says we should
> shoot for 3 to 5 vectors. 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.

I'd suggest s/vectors/dimensions/

But what you're saying is that within each dimension, the relationships
are well-ordered.
>
>
>
> So what vectors should we have? The LoA definition in 800-63 gives us
> a few to work from as starting points, as well as some work that's
> been done in the UK.

A bit of history: 800-63 is a response to OMB M-04-04, which defined 4
levels of assurance. 800-63 is a response to the OMB document describing
how each of the assurance levels should be achieved. During the 800-63-1
revision, there was some discussion about doing something different,
particularly to support the NSTIC strategy's vision of separate identity
and attribute providers. Also, it would have been a major change and it
would have made it less clear how 800-63 is responsive to M-04-04, which
is its primary official purpose. So a paragraph was added to the
introduction (although it doesn't explicitly mention LoA):

> Current government systems do not separate functions related to
> identity proofing in registration from credential issuance. In some
> applications, credentials (used in authentication) and attribute
> information (established through identity proofing) could be provided
> by different parties. While a simpler model is used in this document,
> it does not preclude agencies from separating these functions.



>
>
> *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. 
>
> 0: self-asserted / anonymous / randomized / no idea
> 1: consistent over time / pseudonymous
> 2: proofed in person
> 3: contractually bound

"consistent over time/pseudonymous" is probably also self-asserted.

I notice that you don't have a value for online identity proofing. Was
that an intentional omission?

I'm curious what "contractually bound" is beyond in-person proofing.
>
> *Credential strength:*
>
> This covers how strongly bound the primary credential is to an
> individual presenter, and how easily spoofed or stolen it is.
>
> 0: no credential / public
> 1: shared secret / password
> 2: proof of key possession
> 3: multiple factors [and probably higher definitions here as well --
> but we want to avoid all the little bespoke 2FA companies getting to
> define a special snowflake "credential strength" value or else this
> becomes useless]

Anything here about how the secret key is protected? How about bearer
assertions like cookies?
>
> *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

3 seems like it's addressing a different problem (secrecy) rather than
the verifiability of the assertion.

>
> *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 is probably a mistake to try and smush these back into a linear
> scale like LoA, since that's exactly what we're trying to get away
> from. However, it would probably be a good and enlightening exercise
> to map the existing LoA definitions into these vectors.

I think this is very important, to be able to use vectors of trust with
legacy LOA-based systems. I made an effort to do a mapping like this a
couple of years back, based on a somewhat different vector:
http://www.slideshare.net/jim_fenton/nstic-loa (at slide 9).

>
>
>
> 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: it's essential that we address the accreditation of the
authentication and attribute providers in this structure. It's not clear
that they're additional dimensions, though: a level 3 assertion from an
entity that's only accredited at level 2 should probably just be treated
at the lower level unless there's an indication of fraud. It's also
possible that some providers might be accredited at different levels for
different purposes: perhaps they have an accreditation at level 3 from
the financial community, but only level 2 for health care.  We need to
consider that.

-Jim