Difference between revisions of "Trust Vector"

Revision as of 14:21, 22 October 2018

Full Title or Meme

A collection of Authentication results or Attribute Validations presented to an Authorization Service to control access to a resource, typically digital but possibly physical.

Context

Internet Relying Parties need to perform Knowledge-based functions to determine if the current request by a User should result in Authorization of access.

Problems

• Many large ecommerce sites are already performing this function, but for obvious reasons do not like to let that fact be known.
• If attackers where to understand the process in full detail, they would know how to subvert it.

Solutions

The Trust Vector consisting of the following claims is typically sent together with contextual information in a form that can be processed by a Fraud Detection service.

1. User claims
   1. User assertions
   2. User stipulations (typically User Consent to privacy regulations, but also other user preferences)
   3. User Proof of Presence claims (such as the FIDO U2F specification details)
   4. Inline Validated claims (preformed by Trusted Third Parties and included in the submission from the user)
   5. Online Validated claims (performed by Trusted Third Parties at the request of the Relying Party)
2. Local context
   1. User behavior at the local site now and in the past
   2. Value or risk as determined by the Relying Party

Once the Trust Vector is created it can be passed to a Fraud Detection function together with any context needed to set the parameters of that functions (like the expected value of a fraudulent user.) It the Fraud Detection function is satisfied, the Authorization can proceed. If not the Bayesian Identity Proofing function can be invoked to determine the best way to raise the scoring sufficiently for success and the User queried for additional Attributes or for claims to be Validated.

References

• RFC 8485 Vectors of Trust (2018-10-12) describes a way to move a collection of attributes about a user from an IAP to an [[RP].

Methods for measuring trust in digital identity transactions have historically fallen into two main categories: either all measurements are combined into a single scalar value or trust decisions are calculated locally based on a detailed set of attribute metadata. This document defines a method of conveying trust information that is more expressive than a single value but less complex than comprehensive attribute metadata.

References