Omaerz: 45 revisions imported: Initial Upload of old pages from IDESG Wiki

2018-06-28T04:03:18Z

45 revisions imported: Initial Upload of old pages from IDESG Wiki

New page

=== Overview ===
'''Scenario Name''': Registration and credentialing 
'''Scenario 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.] . 
'''Corresponds to''': Interactions A and B in [[Basic interactions in a single Trust Framework|Scenario: Basic Interactions]] 
'''Use-cases''': [[Credential Issuance Use Case|Use-case #6]], [[Identity Proofing Use Case|Use-case #3]] 
'''Variations''': The following variations are conceivable
====Interface: Web-site====
# Registering and getting a credential at a web site
# Binding different (types of) credential(s) at a web site
# Renewing/resetting credential at a web site

====Interface: Physical Location====
# Registering and getting a credential at a physical location
# Binding different (types of) credential(s) at a physical location
# Renewing/resetting credential at a physical location

 
==== Variation 1: Registering and getting a credential at a web site ====
At a high-level, this can be seen as constituting of 3 main steps, as shown in the picture below.
[[File:IntWG_RegCred_01.jpg]]

Each step consists of possible sub-steps (or alternate ways of achieving that step), as shown in the picture below.
[[File:IntWG_RegCred_02.jpg]]
===== Discover, Reach, Assurance =====
1-A. Discover: It is a step in which the user becomes aware of the services provided by a particular IdP. 
'''IdP's role''': IdP may be involved in advertising their services in appropriate places. 
'''IdEF's role''': IdEF may also provide 'registry/registries' of service providers providing different services. 
'''Security considerations: '''
How do we provide authenticity/validity of the source (for this information)? Quick thought: What happens when this information comes through a phishing email?

1-B. Reach: In this step, the user finds out the specific address where the IdP provides the intended services. For example, this could be a web address (URL) or a physical address. They will then use that address to reach the IdP.

1-C. Authentication: Once the user reaches the location where the IdP services are provided, either through a web address (URL) or physical address, the user needs a way to verify that they are at the right IdP's location. So, they will use some clues (a big board having the business name, for example, in case of physical addresses) to get a guarantee that they are at the right IdP's location. 
'''IdP's role''': Particularly with respect to web interfaces, IdPs must follow well-accepted methods to prove the authenticity of the site to the user - for example, use EV-certificates.
'''Security considerations: '''
Service providers should use valid EV-certificates for any site that provides IDE services. (Implicit: TLS should be used for any IDE services provided.)
Service providers should ensure that their private keys are properly secured and administered.
How to educate users to not ignore certificate validation errors?
'''UX considerations:'''
How to get better indicators (than browser green-coding of locks)?

1-D. Assurance: To utilize the Identity services provided by a particular IdP, the user will need some assurance that the IdP adheres to some rules or laws. This is where a 'IDEF' trust-mark comes into play. 
'''IDEF role''': Provide a secure mechanism for displaying trust-marks. Come up with UX considerations for showing these trust-marks consistently across all participants of IDE. IDE may also be involved in user-education. 
'''IdP's role''': Follow UX and security requirements from IDESG to show the trust-marks.
'''Security consideratons: '''
Trust-marks must be resilient to stealing/counterfeiting.

 

===== Registration =====
In this step, the user explicitly seeks registration operation. IdP may be required to reveal to the user what their security and privacy policies and certifications are (probably just one relevant IDESG trust-mark). 
'''Trust-mark consideration: '''
How can we provide operation specific certification/assurance to the users? Does it mean there is a separate trust-mark/certification/display option for each operation/area combination - for example Registration/security, Registration/privacy 
[[File:IntWG_RegCred_030.png]]

Reg-0: The user finds a way to perform the registration operation. Note: Service providers may provide a list of services they provide, and user selects which one they want to use. 
'''UX consideration[role: IdP]: '''
How to let a user know what (IdP) services this service provider is providing? Is there anything like standardized services we market as part of IDESG? How can the user get assurance on the trust-marks displayed by a service provider? 
'''TrustMark considerations[role: IdP]: '''
What (broad/service-level) trust marks a service provider can (need to) display (on their home page)? 
'''Security considerations[role: IdP]: '''
Registration service/site should continue to use TLS with valid EV-certificates.
Security requirement: Valid version of TLS and related standards (Enc/MD algorithms)
Thought: Can IDESG scan the participant web sites, proactively, to detect malfunctions (certificate errors, other violations)?
 

Reg-1 and Reg-2: IdP provides their security and privacy policy to the user. IdP may also show their (appropriate) IDESG certification to the user. (See above for a discussion of 'appropriate'.) 
'''UX consideration for TrustMarks:[role: IdP] ''' 
'''UX consideration for showing policies:[role: IdP] ''' 
'''TrustMarks consideration: ''' 
How do we provide to user a context-related trust mark - for example, in this case, that the IdP conforms to security and privacy of identity data? 
'''Security considerations:[role: IdP] '''
Any pop-ups used should also be using TLS and EV-certificates
Display when was the last assessment done
 

Registration of identity (or identifier in most cases) may be done in couple of ways - without any identity proofing (providing ownership evidence of attributes used to form the identity), or with identity proofing, as shown here.
In the later case, the process for registering an identifier may be as simple as picking the identifier of choice and confirming its availability.
[[File:IntWG_RegCred_03.png]] 

2-A-1: User is shown a form to pick an IDentifier of their choice and submit it to the IdP 
'''UX consideration for Privacy/security policies:[role: IdP] '''
How can the user know how this site uses their IDentifiers? 
2-A-2: IdP provides an indication of whether the chosen IDentifier is 'available' (meaning no one 'took' it already, satisfies IdP policy for IDentifiers, so on). 
2-A-3: IdP may ask for more attributes from the user. (Note: these attribute values are going to be 'unverified'.)
 If IdP asks for more attributes, it also provides their security/privacy policies and any associated certifications/trust-marks. 
'''UX consideration for Privacy/security policies:[role: IdP] '''
How can the user know how this site stores/uses their attributes? 
2-A-4: User provides attribute values 
2-A-4: IdP provides indication of successful completion of the 'Registration' process.

In case of identity proofing, the notion of 'verifying attribute ownership' will come into picture. The concept of proofing an identity, at the core, means verifying the ownership of certain attributes - the set of attributes chosen may depend on the business (driver's license in some cases, SSN in others, so on). Note that such attributes may uniquely identify a particular person/entity - implying that the policies/certification may be more stringent than for non-verified attributes. 

[[File:IntWG_RegCred_04.png]]
 
2-B-1: Here the IdP is letting the user know that they need to provide attributes for ownership verification - and why it is a required information for registration. Alongside, the security and privacy policies are also presented. The IdP may be required to get a consent (explicit consent) from the user, to collect such attributes. 
'''UX consideration for Privacy/security policies:[role: IdP] '''
How can the user know how this site stores/uses their attributes? 
2-B-2: User is presented a form to fill-in the attribute data. 
2-B-3: User fills in the attribute information 
2-B-4: IdP verifies the veracity/ownership of the entered information. It informs the user that it accepted the entered information. 
2-B-5: User may be allowed to pick an (unique) IDentifier 
2-B-6: IdP confirms to user the validity/availability of the chosen IDentifier(, and indicates that registration step is now complete). 
 

===== Credentialing =====
Credentialing immediately follows registration (same session, so to speak). Some type of credentials may be issued online, and others may require them to be shipped to user's home address (may be applicable for identity-proofed registration, though not necessarily).
[[File:IntWG_RegCred_05.png]]
 
Supported credential types: An IdP may support more than one credential type. If so, they should let the user know which types they support. 
'''UX considerations[role:IdP]: '''
SRD personal request: Can we standardize the password rules through IDESG, please?
'''UX considerations for trust-marks[role:IdP]: '''
How to show context-applicable trust marks?
'''Trust-mark considerations[role:IdP]: '''
How to issue granular trust-marks?

Security policy for storing credentials: 
'''Security considerations[role:IdP]: '''
Minimum security requirements for standard credential types (like passwords, for example)?

Online credential issuance could be a simple process of letting the user pick a credential value that satisfies IdP's rules for that credential type.
[[File:IntWG_RegCred_06.png]]

Offline credential issuance may be more involved (as a. the session is no longer applicable, and b. the credential needs to be shipped to an address that is verified to belong to the user)
====TBD====
[[File:IntWG_RegCred_07.png]]

==== Variation 2: Binding different (types of) credential(s) at a web site ====
'''TBD''' 
Owner:
 

==== Variation 3: Renewing/resetting credential at a web site ====
'''TBD''' 
Owner:
 

==== Variation 4: Registering and getting a credential at a physical location ====
'''TBD''' 
Owner:
 

==== Variation 5: Binding different (types of) credential(s) at a physical location ====
'''TBD''' 
Owner:
 Ann Racuya-Robbins 

==== Variation 6: Renewing/resetting credential at a physical location ====
'''TBD''' 
Owner:

Registration and credentialing - Revision history

Omaerz: 45 revisions imported: Initial Upload of old pages from IDESG Wiki