View source for 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|600px|Basic interactions in an ID eco-system]]

From the above figure, following are the interactions<br />
A. User registers for a digital identity<br />
B. User gets a credential associated with the identity<br />
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<br />
Note: User logs back into the same account at the relying party using the same identity<br />
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'<br />
Y. Relying Party 'gets into the same Trust Framework'<br />
Z. Attribute Provider 'gets into the same Trust Framework'<br />

<br /><br />

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

[[File:AP_Types.pptx|Attribute Provider types]]

<br/><br/>

=== 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.]
<br/><br/>
''Data'': See sub-scenario
<br/><br/>
''Sub-scenario(s)'': [[Registration and credentialing]]
<br/><br/>
''Use-cases'': ??? [Seetharama: I have not seen a particular use case covering the registration flow.]
<br/><br/>
===== Security Considerations =====
===== Privacy Considerations =====
===== Standards Considerations =====
===== UX Considerations =====
===== Policy Considerations =====

<br/><br/>

==== B. User gets a credential associated with the identity ====
''Description'': In this step, the user associates a particular credential to a particular digital identity.<br/>
Note: This step may be repeated multiple times (resetting password, for example).
<br/><br/>
''Data'': See sub-scenario
<br/><br/>
''Sub-scenario(s)'': [[Registration and credentialing]]
<br/><br/>
''Use-cases'': [[Credential Issuance Use Case|Use-case #6]],  [[Identity Proofing Use Case|Use-case #3]]


===== Security Considerations =====
===== Privacy Considerations =====
===== Standards Considerations =====
===== UX Considerations =====
===== Policy Considerations =====

==== 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.
<br/><br/>
''Data'': See sub-scenario
<br/><br/>
''Sub-scenario(s)'': [[Account Creation at, and Login to, RP]]
<br/><br/>
''Use-cases'': [[Authenticate Person Use Case|Use-case #2]], [[Authentication for Enrollment in a Financial Service|Use case #17]]
<br/><br/>

===== Security Considerations =====
===== Privacy Considerations =====
===== Standards Considerations =====
===== UX Considerations =====
===== Policy Considerations =====

<br/><br/>
==== 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.
<br/><br/>
''Data'': See sub-scenario
<br/><br/>
''Sub-scenario(s)'': [[Attribute proofing at AP]]
<br/><br/>
''Use-cases'': [[Identity Proofing Use Case|Use case #3]] ??
<br/><br/>

===== Security Considerations =====
===== Privacy Considerations =====
===== Standards Considerations =====
===== UX Considerations =====
===== Policy Considerations =====

<br/><br/>

==== 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.)
<br/><br/>
''Data'': See sub-scenario
<br/><br/>
''Sub-scenario(s)'': [[Attribute release to RP]]
<br/><br/>
''Use-cases'': [[Selectively Disclose Attributes Use Case|Use case #13]], [[Authentication for Enrollment in a Financial Service|Use csae #17]]

<br/><br/>

===== Security Considerations =====
===== Privacy Considerations =====
===== Standards Considerations =====
===== UX Considerations =====
===== Policy Considerations =====

<br/><br/>

==== 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): 
#SP Recognition (by IDEF)
#Assessor Recognition and Accreditation (by IDEF)
#SP Accreditation (by Assessor)

High-level interactions for each of the sub-scenarios
Service Provider/TF Interactions
#Discovery- Service Provider is able to identify TF that serves the community they are attempting to interact with
#Application for Certification- Service Provider applies for entrance into TF
#Assessment- Service provider is assessed for compliance with TF rules, requirements, and standards
#Certification- Service providers compliance is validated by TF
#Recognition- Service provider is formally recognized by TF (TM, listing service, etc.)

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

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

===== Security Considerations =====
===== Privacy Considerations =====
===== Standards Considerations =====
===== UX Considerations =====
===== Policy Considerations =====


[[Category:Trust]]
[[Category:User Experience]]
[[Category:Interoperability]]
[[Category:Privacy]]
[[Category:Security]]