Trust Elevation Use Case: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
m (71 revisions imported: Initial Upload of old pages from IDESG Wiki)
 
(No difference)

Latest revision as of 04:04, 28 June 2018

Template:Comment

Use Case Metadata

Title

Progressive Authentication

Status

Use Case Lifecycle Status

Contributed Working Draft Committee Review Compilation Approval Publication
This use case has been approved in version 1.2. This page may have been updated since the 1.2 document was approved.

Use Case Category

Trust, Assurance, Authentication, Interoperability, Privacy

Contributor

Tom Jones, Editor

Use Case Content

Use Case Description

Migrate from anonymity to establishing a user’s identity with an unverified identity claim (aka pseudonym) and raise the level of authentication using credentials with higher trust levels as needs dictate. The particular scenario described below is based on a user that has a low trust identity at some benefits provider that needs to be elevated in order to complete a sign up for benefits. This use case focuses on a single elevation jump from non-validated ID to one that is proofed by a trusted third party. The real world is always more complex and may involve multiple steps as more resources are accessed. If the Levels of Assurance for NIST SP800-63 are used the sequence should use the following hierarchy.

Anonymous --> LoA 1 --> LoA 2 --> LoA 3 --> LoA 4

  1. provides some assurance of the same Claimant who participated in previous transactions (Pseudonym)
  2. provides single factor remote network authentication with identity proofing
  3. provides multi-factor remote network authentication with cryptographic strength mechanisms
  4. provides proof of possession of a key using a cryptographic protocol with in-person proofing at registration

Actors

  • Financial institution - typically a federal depository institution (FDI).
  • Benefits providers - typically a governmental entity (e.g. SNAP also known as food stamps) that fills the role of attribute verifier. The claims provided by a benefits provider have nearly the exact opposite meaning of claims in the case of (e.g.) a health insurance provider. In this case the claim is an assertion of the availability of compensation to the RP for service provided to the user.
  • User - typically a human being acting through a user agent that needs to evaluate benefits of service providers (RPs).
  • Relying parties (RP) - a provider of services to the user.
  • Identity providers - typically a government sponsored provider (state DMV, contractor, etc.)

Goals / User Stories

  • Allow immediate access to the relying party without revealing user private data.
  • Request private date from user only when required to access high value resources of the relying party.
  • Fraud reduction which may imply cost reduction for the relying party.
  • Viable business model for the identity provider.

Assumptions

  • The relying party has a service to offer that the user needs to understand better before making a commitment to offer more of their own identity to the relying party.
  • The relying party requires an external proofing service to provide a higher level of assurance before full access to site may be granted.
  • The User has a device with internet access. [Moved from requirements when applying new template]
  • The User Agent is trusted by the user to collect claims from providers for a limited validity period and provide them to the relying party using a policy provided by the user.
  • Relying Party has a list of trusted providers (or ecosystems) that should be displayed for the user to chose.

Process Flow

  1. The user accesses the relying party anonymously seeking information about the service offerings. (Flows 1 and 2 in the accompanying figure.)
  2. The user wishes to establish a profile to create a continuing identity with the site.
    1. The site offers a selection of identity providers, perhaps including itself. (Flows 3 and 4)
    2. Each identity provider choice includes a link to acquire a credential.
  3. The user goes to that identity provider and satisfies their need for high level authentication as required by the relying party. (Flows to the IdP)
  4. The user device receives and stores the credential in the manner consistent with the level of assurance required by the relying party.
  5. The user returns to the relying party and continues the access for services that are personalized for that identity. (Flow 5)
  6. The user seeks to acquire high value services which causes the relying party to request claims that include the user's real ID from the user’s device. (Flow 6)
  7. A user agent on the user device determines if the user:
    1. Has the proof-of-presence needed for authentication (e.g. biometrics)
    2. Has protected the credential at the required level.
    3. Verifies the identity of the relying party.
    4. Has authorized the release of the information to the relying party.
  8. The user agent sends a collection of claims as authorized by the user. These claims can come from the IdP as well as other providers as required by the relying party. (Flow 7)
  9. The relying party either accepts the collection of tokens or requests more. Note that it is entirely the responsibility of the relying party to determine if the identity and attribute claims are sufficient to allow access. The user many have held back some claims for privacy reasons the prevent the relying party from granting access.
  10. The user agent my respond with more information or not as authorized by the user and returns to step 6 or terminates. There is no guarantee that the user will have (or release) all of the claims needed by the relying party to grant access.
  11. When the Relying party has received sufficient claims from the user the services are provided. (Flow 8)

File:TrustElev.png

Success Scenario

This scenario is designed to show how trust elevation would work in a real world case of a citizen of a state that wanted to understand the benefits that might be available to them before applying for those benefits.

  1. User can access the benefits office to determine what benefits are offered and how they can qualify to receive them.
  2. The benefits offices has access to a high assurance identity provider, such as the DMV.
  3. The user has the ability to access the identity provider.
  4. The user is required to visit a benefits office in person one time to provide proof of presence. (Deputy Registrars are enabled to provide this service in many state office buildings and approved notary publics in banks and other institutions.)
  5. A credential (like a smart card) is available to the user to acquire the authorized benefits.
  6. The user is able to revalidate their access to the benefit as often as required to maintain timely access to the benefit.


Error Conditions

  1. User does not have the credentials required by the relying party. Mitigation: the relying party redirections the user to one or more sources of appropriate credentials.
  2. User cannot acquire the requisite credentials. Mitigation, the user needs to find the proof needed to satisfy one of the identity providers acceptable to the relying party.

Relationships

References and Citations

NSTIC Guiding Principles Considerations

Privacy Considerations

Note that there is no reason for validation of attributes until the user decides to ask for specific resources (benefits in the present use case.) However it is known that search terms alone are sufficient in many cases to allow identification of the user. In any service that collects attributes or behaviors of the user over time, only policy enforcement will offer any hope of blocking discovery of the user's identity. Implementers should consider implementations that do not allow parties to the transaction to correlate users with relying parties.

Security Considerations

As described in the interoperability section below, the context and hence the security requirements for information interchange between the user and the relying party can change radically even within a single session. As a result the relying party should make the assumption from the very beginning that it must present a secure identification of itself (e. g. with EV certifications) from the very beginning. While not mandatory, it is suggested that a fully encrypted channel exist from the beginning as well; that would prevent certain attacks that could leak user information by creating exploits of the low trust connection that survive the transition to a high trust connection.

User Experience/Usability Considerations

Since the essence of this use case involves the elevation of trust between the user and the relying party, the user expectation need to be carefully managed. A single browser session may change from fully anonymous to sharing of highly confidential information about the user's financial condition in a matter of minutes.

Interoperability Considerations

This use case describes a capability for progressive authentication which creates the possibility that different trust frameworks, and hence different Trustmarks, will apply for different interactions. It is even likely that the same connection between the user and the relying party will experience a trust elevation. It will be a challenge to create a information sharing protocol that is able to change contexts from full anonymous to deeply personal.

Domain Expert Working Group Considerations

Financial

Many benefits exchanges have the same effect as a money exchange for the user. It is to be expected that financial institutions will be involved in some of these exchanges and so constraints on value exchanges could be treated as financial transaction by regulatory bodies.

Health Care

Where the benefit requested by the user is for health care, the terms of HIPPA might begin to apply at some point in the information interchange. As described in the security section, any site that has any expectation of potential HIPPA applications should begin all interchanges as though it applied from the start even during an anonymous first stage interchange.

Derived Requirements

Most derived requirements only apply to the implementation of this use case.

References

Progressive Authentication at http://tcwiki.azurewebsites.net/index.php?title=Progressive_Authentication#Context

Retrieved from "https://wiki.idesg.org/index.php?title=Trust_Elevation_Use_Case&oldid=8156"