In order for user enrollment to work at a Relying Party (RP) it needs a shared private piece of data that represents a claim of identity (e.g. SSN, Drivers License #) and a set of information that can be used to prove the claim. The manner in which the RP obtains the latter depends to a great degree on the identity verification model that is used. This blog post describes the steps and considerations regarding attribute movement for the purpose of user enrollment.
The steps in this process, from the perspective of the RP, are:
- Determine the minimal set of attributes (attribute bundle) needed to uniquely identify a person, map them into an existing record at the RP or create a new record if it does not exist
- If the attributes are Personally Identifiable Information (PII), implement the necessary protections (both policy and technology) needed to safeguard them during collection, transit, and at rest
- Determine who will collect, verify and bind the attributes to an identifier, and if the assurance level of that binding is acceptable
- Determine the secure mechanism needed to move the attributes from the entity that collected them to the Relying Party
1. Determine the minimal set of attributes
What is the minimum set of attributes needed to uniquely identify a person within a system?
- Can we standardize this "attribute bundle" across multiple systems? e.g. Does the combination of Social Security Number, Date of Birth, State of Residence serve to uniquely identify a person? More? Less?
2. Implement PII Protection on collected attributes
- Has a Privacy Impact Assessment been done that includes clear identification of the data needed and collected?
- Do you have the authority to collect this information? How will you track and verify user consent?
- Have you implemented technical and policy protections on PII information as required?
3. Who will collect and verify the attributes?
- Will the attributes be collected and verified by an Identity/Credential Provider or a Registration/Identification Service?
- Will the attributes be collected by the Relying Party and be verified directly or by leveraging a third party service?
- Is the verification of attributes and the binding to an identity comply with NIST 800-63-1(PDF) identity proofing requirements?
- If the verified attributes provided by the IdP/CSP/AP are not sufficient, do you need to implement the ability to request the data directly from the citizen or implement an attribute request/verification capability with a third party service?
4. How will you securely move the attributes?
How will you move the verified attributes from an IdP/CSP/AP to the RP?
- Will the attributes be sent every time by the IdP/CSP/AP to the RP? Is there a mechanism to provide a hint regarding first time enrollment?
- Does support for using an out-of-band attribute call to the IdP/CSP/AP exist with all entities in the flow? If needed, what will you use as the identifier?
- Does the ability to capture and pass consent regarding attribute release exist?
One other attribute movement mechanism that is often used by Enterprise as an IdP, is to out of band provision an RP via some sort of an Identity Bridge mechanism. That particular use case comes into play when you are connecting the Enterprise to a SaaS Provider. That use case is out of scope.
Feedback on how you are implementing these types of capabilities in your Enterprise would be appreciated. Are there additional or different approaches or considerations?
:- by Anil John
