Vectors of Trust

From IIW
Jump to: navigation, search

Creating Vectors of Trust

Wednesday 1A

Convener: Justin Richer, and presentation by Jim Fenton

Note Taker(s): Oscar Manso

This work started at an Internet Society meeting last Fall, and spun up an IETF non-wg list. To review the list archive and/or subscribe, see https://www.ietf.org/mailman/listinfo/vot


                Identity Proofing      Credential		
    Zero	  Anonymous	           Session
    Low	     Pseudonymous-Self	       User/pwd
    Medium    (Some minimum auth)
    High


In terms of credential assurance, vendors will like to be able to add their own flavours to signify their difference In order to transfer these values across the wire to the RP the proposition is to send a vector of values:

[I2:C3]

[I0:C3] -> This one can be very appropriate for the health sector

You need to be able to verify where is this identity information coming from because otherwise you are in trouble…

In terms of credentials assurance for mobile devices there are three main elements to take into account:

Strength of auth method + Credential secure against malware + credential is protected against physical capture of the device

Justin suggests that if this is done at such a high level, this type of definition may explode and may make not sense for many type of credentials… that said, if this information can be conveyed at a higher level, that could be very interesting….

Another category that has been suggested to include is environment. But environment in respect to what? If it is in respect to the IdP, this can be considered as quite static and therefore, can be conveyed in a different manner…

Another environment more dynamic is the Auth Context, how was the authentication being presented?

Another approach to look at all this is to define it as a set of attributes for everything… this may explode too much… everybody will be looking for their own attribute and their special definition…Justin feels that we should end up with between 2 and 5 vectors…

Another proposition is to consider the values linked to the attributes in a more fluid manner but then, the result may not make any sense at all for the Relying Party…

Should we have a mechanism for an attribute bundle to allow for particular cases?

Jim indicates that there is an Executive Order 13681 released in October 17, 2014 that aims to improve the security of consumer financial transactions: https://www.federalregister.gov/articles/2014/10/23/2014-25439/improving-the-security-of-consumer-financial-transactions

The distinctions defined need to be meaningful otherwise that won’t make sense.


Level of Assurance can be split into two parts:

+ Level of Strength (of authentication)

+ Level of Confidence (of attributes)

He proposes three levels of strength…


Eve also introduces that this is a communication problem for consumers in the context of UMA… and consumers could not understand more than three levels… Another point is that if we define a static system to start with we may be thinking on a more dynamic system that could evolve in the future…

--

Jim Fenton presented his proposed approach, slides at http://www.slideshare.net/jim_fenton/loa-alternatives-a-modest-proposal

VoT a.jpg

VoT b.jpg


Additional Notes from the session

Notes-taker: Jim Fenton

Tags for the session - technology discussed/ideas considered:

Authentication

Proofing

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

'Vectors of Trust' - many people hate the term but haven't gotten any better suggestions

A vector in the mathematical sense -- not physics

Currently an IETF Internet-Draft -- looking to go through individual submission track to RFC

Candidate components:


Proofing

Credential

Management

Assertion


Each has levels associated with it

e.g. P0 = self-asserted, P3 = contractual relationship


In ID token, a new claim, e.g.,

"vot": "P2.C3.M2.A1"


This will accommodate strong pseudonymity, e.g., "P0.C4.M2.A3"

Context for this: "vtr":"https://.../"


Some elements can be repeated...perhaps if more things are being used to increase trust

So multifactor authentication might be P0.C2.C3.A3 (perhaps a password and a FIDO token) or alternatively perhaps a P0.C4.A3

Trying to strike a balance between expressivity and excessive complexity for relying parties. Needs to be “stupidly easy” for RPs to process.

VoT does not define an ordering for values within a category, but a given “vtr” may specify that they are ordered.