High Assurance AZ Token: Difference between revisions
Jump to navigation
Jump to search
| Line 5: | Line 5: | ||
* The page is directed to the problem of providing high assurance identifier tokens that can be used for high volume use cases, such as health services. | * The page is directed to the problem of providing high assurance identifier tokens that can be used for high volume use cases, such as health services. | ||
*Existing standards for identifier tokens are based on the assurance of the trust of the [[Relying Party]] (aka client) in the tokens produced by the Identifier provider, typically on of the well-known social sites. | *Existing standards for identifier tokens are based on the assurance of the trust of the [[Relying Party]] (aka client) in the tokens produced by the Identifier provider, typically on of the well-known social sites. | ||
*To get high assurance identifiers, the web site that wants the higher level of assurance (whether RP or IDP) will perform additional validation of the user with protocols like [[ | *To get high assurance identifiers, the web site that wants the higher level of assurance (whether RP or IDP) will perform additional validation of the user with protocols like [[FIDO Universal 2nd Factor (U2F) 1.x]] or Web Authentication (aka Fido 2.0). | ||
==Problems== | ==Problems== | ||
* The IdP needs to be trusted by the RP. That can be difficult to achieve when the RP has the high value resource that the user wants to access. | * The IdP needs to be trusted by the RP. That can be difficult to achieve when the RP has the high value resource that the user wants to access. | ||
Revision as of 03:48, 5 March 2020
Full Title
Structure of a stand-alone Token that can provide high assurance of (1) Identity, (2) Authentication and (3) Federation in high volume, universally accessed web services.
Context
- The page is directed to the problem of providing high assurance identifier tokens that can be used for high volume use cases, such as health services.
- Existing standards for identifier tokens are based on the assurance of the trust of the Relying Party (aka client) in the tokens produced by the Identifier provider, typically on of the well-known social sites.
- To get high assurance identifiers, the web site that wants the higher level of assurance (whether RP or IDP) will perform additional validation of the user with protocols like FIDO Universal 2nd Factor (U2F) 1.x or Web Authentication (aka Fido 2.0).
Problems
- The IdP needs to be trusted by the RP. That can be difficult to achieve when the RP has the high value resource that the user wants to access.
- The users are accustomed to using the "free" social media sites as an IDP that will be trusted by the RP.
- The liability associated with high assurance IDPs is not likely to be available on "free" social media sites.
- The assurance associated with out-of-band assurance, like web authentication has not been successful with the large number people that are expected to be using high assurance sites, like health services.