Basic interactions in a single Trust Framework

Overview

Scenario Name Basic interactions in a single Traust Framework

Scenario Description This scenario captures the high-level interactions a user performs in the ID eco-system. Only the basic operations/interactions are captured. Sub-scenarios can capture more granular interactions, or other high-level scenarios can capture other types of interactions (litigation, for example).

Corresponds to None

File:Scenario-high-level-uses-singleTF.png

From the above figure, following are the interactions
A. User registers for a digital identity
B. User gets a credential associated with the identity
Note: This may be repeated multiple times, sub-scenarios need to capture what 'credential management' may involve C. User opens an account with a relying party using the above identity
Note: User logs back into the same account at the relying party using the same identity
D. User encounters a situation where they need to provided (proofed) attributes to an RP. User chooses a particular AP (based on some criteria) and undergoes the proofing process (if required for a given attribute) with the AP. E. User authorizes release of specific attribute values from the AP to the RP

X. Identity Provider 'gets into the Trust Framework'
Y. Relying Party 'gets into the same Trust Framework'
Z. Attribute Provider 'gets into the same Trust Framework'

Attribute Provider types

Below document captures different manifestations of attribute provider services that are possible in the ID Ecosystem.

File:AP Types.pptx

Interaction Details

More detailed description for the interactions are

A. User registers for a digital identity

Description: In this step, the objective is that the user registers a particular digital identifier for their use. [Note: It may be possible that registration of a digital identifier by itself, without associating it with a particular credential, is not a stand-alone step.]

Data: See sub-scenario

Sub-scenario(s): Registration and credentialing

Use-cases: ??? [Seetharama: I have not seen a particular use case covering the registration flow.]

B. User gets a credential associated with the identity

Description: In this step, the user associates a particular credential to a particular digital identity.
Note: This step may be repeated multiple times (resetting password, for example).

Data: See sub-scenario

Sub-scenario(s): Registration and credentialing

Use-cases: Use-case #6, Use-case #3

C. User opens an account with a relying party using the above identity

Description: In this step, the user wants to use their digital identity to open an account at an RP, and login in to that same account using the same digital identity at later points in time.

Data: See sub-scenario

Sub-scenario(s): Account Creation at, and Login to, RP

Use-cases: Use-case #2, Use case #17

D. User proofs attributes to AP

Description: In this step, the user proves to a particular AP that they own certain attributes (more like attribute-value pairs). The AP then registers those attribute values against the digital identity provided by the user (after verifying the user's ownership of that specific digital identity, possibly through some login process that involves the IdP). Additionally, the AP may register the specific credential (type) used to register the attribute(s), and thus require same (type of) credential at the time of access.

Data: See sub-scenario

Sub-scenario(s): Attribute proofing at AP

Use-cases: Use case #3 ??

E. User authorizes release of specific attribute values from the AP to the RP

Description: In this step, the user wants to provide RP with certain attributes that they own. User does this by essentially authorizing the RP to get the values of the specific attributes from the AP. This will involve the user verifying their identity (using the particular credential used at the time of registering the attribute) at the AP (through an interaction with the IdP.)

Data: See sub-scenario

Sub-scenario(s): Attribute release to RP

Use-cases: Use case #13, Use csae #17

X. Trust Framework interactions with Service Providers

Description: The trust framework (IDEF) will need to make clear to the participants (both the users and the service providers) what services it provides to them to support the overall framework. Particularly for service providers, who have to go through accreditation, have trust relationships with other service providers, be interoperable overall, and so on, it is important to identify how they can do all these functions within the eco-system.

Data:

Sub-scenario(s):

1. SP Recognition (by IDEF)
2. Assessor Recognition and Accreditation (by IDEF)
3. SP Accreditation (by Assessor)

High-level interactions for each of the sub-scenarios Service Provider/TF Interactions

1. Discovery- Service Provider is able to identify TF that serves the community they are attempting to interact with
2. Application for Certification- Service Provider applies for entrance into TF
3. Assessment- Service provider is assessed for compliance with TF rules, requirements, and standards
4. Certification- Service providers compliance is validated by TF
5. Recognition- Service provider is formally recognized by TF (TM, listing service, etc.)

Assessor/TF Interactions

1. Discovery- Assessor is able to identify TFs
2. Application for Accreditation- Assessors applies for accreditation through the TF
3. Accreditation- Assessors practices are evaluated and validated by the TF to determine if they are consistent with TF and community assessment and certification needs
4. Recognition- Assessor is formally recognized by TF as capable of carrying out assessments of service providers to support certification

Assessor/Service Provider Interactions

1. Discovery- Service providers are able to identify compliant Assessors for the TF from which they are seeking certification
2. Agreement- Service provider and Assessor enter into agreement over assessment process
3. Evidence Presentation- Service providers grant Assessor access to evidence necessary to determine compliance with TF
4. Assessment- Assessor reviews evidence and provides attestation of compliance to TF for certification determination