Vectors of Trust

Vectors of Trust

Wednesday 9C

Convener: Justin Richer

Notes-taker(s): Thomas Berry

Tags for the session - technology discussed/ideas considered:

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

Topic: RFC 8485 Vectors of Trust

P Proofing

C Credential

M Management

A Assertion

OMB 0404 Trust Frameworks

Full attribute provenance.

How assured can you be about “that” person.

If someone has a really strong credential, in order for that to mean anything that has to be proofed to a real identity.

Other end of the scale, every attribute I get something about you, when was it last time it was verified; is that verified?

If you’re a relying party and get info about the person and its attributes, calculate that to determine if the person should login... can’t do it.  Give them a numeric value and an RP can do the math.

You have an anonymous whistleblower that isn’t tied to an identity; the proofing should be explicitly zero; but, you need to make sure the “account” hasn’t been taken over by someone else.

800-63 rev 3 also has a multi dimensional approach to identity assurance

Vectors of trust comes from the computer science array, not mathematical concept

Need the real-world identity proofing from the credentialling

Proofing: How do I know you are YOU

Credential: Are you using (password|token|MFA) 

Management: How is the association managed from proof to credential

Assertion: how does this get carried across the network (signed ID token, encrypted, multi-holder of key)

All of this gets “boiled-down” into a framework.

As defined by RFC 8485:

P1 All attributes have been self-asserted 

.Cc you used a password

.Cb some holistic thing was used

.Mb approved management

.Ac passed by the browser

P1.Cc.Cb.Mb.Ac can now be thrown into a data structure without encoding

This is really simple to parse without a dedicated parser library.

The IdP can make this statement as part of the ID token “vot”:”P1.Cc.Cb.Mb.Ac”

sub:...

iss:...

exp:...

vtm:http://tools.ietf.org/html/rfc8485

RP can now simply look for the accepted vot:

I need a P1

And, maybe other parts of the category if necessary.

Could be easy as relying on the IdP to establish proof of identity

Use Case: Need something more than a cookie, the authentication can be requested/proofed-credentialed, etc.

The string within the construct of a trust framework can be translatable into a level of assurance (i.e., LOA2); although the RFC doesn’t define LOA at all, but it does state it is perfectly acceptable to have a set of translation rules to take the vot value and return a LOA value...   If it turns out you need to know when “this” was validated and “who” did the validated, vot doesn’t get in the way of the query when it is needed.

NIST IR 8112 scratches around the edge of this, but doesn’t define a protocol but does provide a framework with metadata of attributes.

VoT allows RPs that want to be smart to do so.

Trust Frameworks:

• VoT only makes sense within the context of a trust framework
• IdP and RP need to agree with the VoT as it applies to the mutual trust framework

NIST document (unreleased)

Defines a set of vectors of trust values for new 800-63rev3

Does not have a publication target yet

IAL maps to  P proofing

AAL maps to  C credential

M management

FAL maps to  A assertion

If you have your own trust framework, this can be extended:

X - hair color

IANA registry for extension categories of VoT framework

NIST framework brings priority of categories

Used as custom within health care space (integrated with OIDC IdP)