Selectively Disclose Attributes Use Case

Use Case Metadata

Title

Selectively Disclose Attributes

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

Attribute Management

Contributor

Matthew Thompson, Editor

Use Case Content

A Claimant possesses multiple attributes and is eligible for different benefits and/or online services from a Relying Party based on specific attributes. The attributes addressed in this use case can include identity attributes (i.e., name, address, phone) and biographical attributes (i.e., age, individual certifications, professional affiliations). The Relying Party offers a benefit or service if the claimant discloses the attribute in order to prove eligibility for the specific program. In this use case, the Relying Party is only interested in the specific attribute information and the claimant needs a way to disclose that attribute information.

File:John Doe.png

Actors

• Claimant: a human individual who wants to demonstrate some claim of an attribute.
• Relying Party: an organization wanting to deliver a benefit or service to individuals possessing specific attributes.
• Attribute Verifier:
• Registration Authority:

Goals / User Stories

John realizes that he is eligible for a benefit from an organization that offers an exclusive benefit/service for people who possess the same attribute as John. The organization wants to verify that John is actually eligible for the benefit/service to protect themselves from fraud or abuse. John is able to provide the minimum necessary information to a third-party attribute verifier who then matches that information against an authoritative source. John is able to review the information before it is shared back to the organization offering the benefit. If John authorizes the release of the information, the organization unlocks the benefit/service to John based on a "yes" or "no" response. The goal of this use case is to protect John's privacy while giving him access to the benefit and at the same time protecting the organization from fraud and abuse. The organization is also able to grow their market share with the community of people possessing specific attributes.

Assumptions

• Relying Party only requires the attribute information be verified and not the identity of the claimant.
• The Relying Party does not need to uniquely identify a single person.
• Relying Party requires the attribute information to be verified against an authoritative source.
• An authoritative source exists to proof the attribute assertion of a claimant.
• Attribute Verifier is able to verify the attribute information of a claimant against the authoritative source.
• Relying Party has an existing relationship with an Attribute Verifier that provides an acceptable level of assurance based on the value and risk of the benefit or service.
• Attribute is bound in some way to limit its scope. That can include (but is not limited to) a pseudonym, timestamp, session ID or other item that will prevent a replay of the attribute claim.

Process Flow

1. A Claimant sees they are eligible for a benefit or service on a Relying Party site based on an attribute the user possesses.
2. The Claimant chooses to prove to the Relying Party that he possesses the attribute and qualifies for the benefit or service.
   • The claimant verifies attribute information with an acceptable Attribute Verifier.
3. The Attribute Verifier performs a match with the authoritative database associated with the particular attribute.
4. The Attribute Verifier presents the results of the match against the authoritative database and gives the user control of whether or not that information is shared with the Relying Party.
5. Upon authorization by the Claimant, the Attribute Verifier passes the minimum attribute information to the relying party to prove the Claimant is eligible.
6. The Relying Party unlocks the benefit or service for the Claimant upon receiving confirmation from the Attribute Verifier that the user is qualified.

File:Process Flow.png

Success Scenario

• The Claimant is able to access a benefit or service online by proving that they possess a specific attribute.
• The Claimant is then able to disclose their attribute information without having to reverify.
• A Relying Party realizes a reduction in risk through the use of verified attributes
• A Relying Party is able to grow market share and loyalty with people possessing specific attributes

Error Conditions

• The Claimant possesses the attribute, but is not able to verify that attribute with the Attribute Verifier.
• The Claimant does not possess the attribute, but is able to verify through the Attribute Verifier and fraudulently access the benefit or service.
• Someone other than the claimant is able to present the attribute token in a replay outside of the authorized scope and gain access to the benefit or service.

References and Citations

• FTC Fair Information Practice Principles http://www.ftc.gov/reports/privacy3/fairinfo.shtm
• NSTIC: http://www.whitehouse.gov/sites/default/files/rss_viewer/NSTICstrategy_041511.pdf
• NIST SP 800-63-2 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf

NSTIC Guiding Principles Considerations

Privacy Considerations

1. Claimant should be able to voluntarily participate in the process.
2. Claimant should control the rights to their own data and that Claimant's information should only be released to a Relying Party at the claimant's discretion.
3. Organizations shall limit the collection and transmission of information to the minimum necessary to fulfill the transaction's purpose and related legal requirements.
4. Claimant should be able to voluntarily participate in the process.
5. Claimant should control the rights to their own data and that Claimant's information should only be released to a Relying Party at the claimant's discretion.
6. Organizations shall limit the collection and transmission of information to the minimum necessary to fulfill the transaction's purpose and related legal requirements.
7. Same concerns about the identifying properties of validated attributes as above use cases.
8. Attribute provider appears to pass info directly to the relying party, enabling it to track the claimant's interactions with the relying party.