Vectors of Trust
Vectors of Trust
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
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”
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.
- 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
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)