Difference between revisions of "Trust Vector"
From MgmtWiki
(→Solutions) |
(→References) |
||
| (16 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | + | A collection of [[Authentication]] results or [[Attribute]] [[Validation]]s presented to an [[Authorization]] Service to control access to a resource, typically digital but possibly physical. | |
==Context== | ==Context== | ||
| − | + | Internet [[Relying Party|Relying Parties]] need to perform [[Knowledge]]-based functions to determine if the current request by a [[User]] should result in [[Authorization]] of access. | |
==Problems== | ==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== | ==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. | ||
| + | # User claims | ||
| + | ## User assertions | ||
| + | ## User stipulations (typically [[User Consent]] to privacy regulations, but also other user preferences) | ||
| + | ## User [[Proof of Presence]] claims (such as the [[FIDO U2F]] specification details) | ||
| + | ## Inline [[Validated]] claims (preformed by [[Trusted Third Parties]] and included in the submission from the user) | ||
| + | ## Online [[Validated]] claims (performed by [[Trusted Third Parties]] at the request of the [[Relying Party]]) | ||
| + | # Local context | ||
| + | ## User behavior at the local site now and in the past | ||
| + | ## 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 [[Attribute]]s 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]. | ||
| + | <blockquote> 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.</blockquote> | ||
==References== | ==References== | ||
| Line 17: | Line 31: | ||
[[Category:Glossary]] | [[Category:Glossary]] | ||
| + | [[Category:Authorization]] | ||
| + | [[Category:Trust]] | ||
Latest revision as of 23:43, 14 February 2019
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.
- User claims
- User assertions
- User stipulations (typically User Consent to privacy regulations, but also other user preferences)
- User Proof of Presence claims (such as the FIDO U2F specification details)
- Inline Validated claims (preformed by Trusted Third Parties and included in the submission from the user)
- Online Validated claims (performed by Trusted Third Parties at the request of the Relying Party)
- Local context
- User behavior at the local site now and in the past
- 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.
