Re: [VoT] Vectors of Trust: A Strawman

[Nat Sakimura <[e-mail]>]

2014-10-03 7:07 GMT+09:00 Jim Fenton <[e-mail]>:

>  Hi Justin,
>
> Good kickoff!
>

+1


>
>
> 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.
>

Not sure about it. There can be pseudonymous - time consistent identifier
which is based on well vetted core identity. A prime example is Austrian
eID. A sector specific pseudonym is generated from LoA4 Qualified
Certificate.


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

Right. Also, having proofed in person / online and the assurance level of
the proofing is kind of orthogonal. There are many cases of lousy in-person
proofing, and there are cases of excellent online proofing.

The same is true for the contractual binding. It depends on the quality of
contract.

OK. I am running out of time. I will respond to the below at a later time.

Cheers,

Nat


>
> 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
>
> _______________________________________________
> vot mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vot
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en