Talk:Remote Electronic Identity Proofing Use Case

From IDESG Wiki
Jump to: navigation, search

Suggested abstraction of this use case

Note: this discussion responded to an earlier version of the case... Andrew may have responded to some of the thoughts.

Use Case Description: Separate proving identity from issuing a credential based on that identity. Provide for an Applicant (A) to interact with an Identity Verification Provider (IVP) to provide identifing information, and for the IVP to communicate the identifying information to a Registration Authority (RA), that will issue a credential based on that identity.


  • Applicant (A) [a person]
  • Identity Verification Provider (IVP)
  • Registration Authority (RA)

Goals:A wants to obtain a credential from RA. RA wants to have assurance of A's identity, without having to interact directly with A. Supply needed assurance without requiring physical, in person meeting(s) between A and IVP or RA.

Assumptions:The level of assurance (LOA) needed for the credential would require a physical, in-person meeting to establish identity, in current practice. RA and IVP have a business relationship establishing what forms of identifying information are needed for particular applications.

Process Flow 1: (in the original use case) A applies to RA. RA notifies IVP of application, notifies A of IVP, and pays IVP for service. IVP sends template for identifying information to A. A fills in template and returns it to IVP. IVP reviews identifying information. IVP arranges online video session with A. In video session IVP records verbal attestation to identifying information by A, and attests to genuine appearance of identifying documents shown by A, and appearance of A. IVP sends identifying information and attestation to RA.

Process Flow 2: A applies to IVP, naming RA. IVP sends template for identifying information (as required for RA) to A, and interacts with A as in Process Flow 1. IVP invoices RA.

Success Scenario: A supplies identifying information to IVP; IVP transmits identifying information to RA. Error conditions: IVP provides false identifying information to RA. Communication of identifying information between IVP and RA is not secure. Credential is issued to a person other than A. IVP provides insufficient identifying information to RA, so that credential cannot be issued. Communication between A and IVP is not secure. A provides identifying information to an entity other than IVP. A lacks the functional abilities and/or equipment needed to interact with IVP.


  1. My intentions in creating this version of the use case were:
  • To reduce some of the implementation dependencies.
  • To focus on the key actors. Other actors may come into play, for example if the implementation uses electronic signatures, as suggested in the original use case.
  • To make explicit more of the error conditions, including the possibility of user-oriented issues re A.
  • To suggest that alternative process flows are possible, opening up somewhat different business roles. In Process Flow 1 IVP is strictly a B to B player, whereas in Flow 2 IVP could be B to C.
  1. The suggested flows embed current assumptions about the role of human notaries, attesting that documents look genuine, and that the applicant looks like the picture on their picture ID. Does the evolution of the identity ecosystem open up new approaches to this, for example via biometric links in electronic credentials? What will the relationship be between the notary system of today, including how notaries are appointed, and the IVPs of the future?

Review points for Use Case

The review for this Use Case offered by Clayton Lewis has provided considerations which suggest the need for specificity levels of Use Case development commensurate with IDESG goals. For example in developing this Use Case for Remote Electronic Identity Proofing we sought to comply with the template categories without consideration for Use Case work shop analysis or subsequent full on adoption by IDESG. Additionally Clayton's review exposed a myopic view where the Use Case did not include a bi-linear approach that would allow general public trust credential acquisition which may include remote identity proofing with an IVP having a trust relationship with an RA/CA. The previous version only provisioned RA approved RA authorization for an individual to acquire a trust credential.

Also the original version convoluted the actor/relying parties role. Review points provided by Clayton helped to clear the stage provide clarity for the respective roles. "Error" consideration was also expanded.

Overall Clayton's review was very helpful in the continued development of this Use Case and greatly appreciated. As a result the Use Case for Remote Electronic Identity Proofing has been amended.

Scott's review

Hi Andrew, sorry to keep you waiting for my review. Review is ongoing, I'll update (and email you) when it's complete.

  1. Please rename the use case to "Remote Electronic Identity Proofing Use Case" <- trying to put Use Case in the name so people know what they are seeing right away. Done.
  2. Actors - there are system level and non-system level actors right now.
    1. RA is typically a human agent - system level
    2. CA is typically a server - not system level
    3. The "PKI" actor seems to comprise the CA and RA.
    4. The device is not system level Discussed and resolved.
  3. Goals
    1. I like the word "distal" but it seems redundant with "remote". Is there a particular sense of remote that distal is intended to convey? Resolved by adding a definition of the sense of distal as a remote applicant with an antecedent relationship that the RA can use.

Andrews reply

Scott first thank you very much for your review. We will amend the Use Case to reflect your first observations. However I would like to address your comment and question regarding potential redundancy using both "distal" and "remote":

"I like the word "distal" but it seems redundant with "remote". Is there a particular sense of remote that distal is intended to convey?"

The use of these two words were contemplated to be mindful of a comment from a rejection notification we received on one of our utility applications for a patent from a USPTO examiner who stated,

"Claim 1 recites the limitation "at a location that is distal from a pre-registered notary" in line 5. At issue is the use of the word "distal" to describe the location of the device. As understood by Examiner, "distal" is a term in biology that describes something that is farthest removed from a point of attachment or origin. On this basis, it is unclear how a data input input device can be "distal" from a pre-registered notary. "Distal" is not a synonym for remote or distant and will not be treated as such."

As a result from this POV I thought to state both the word distal and remote to include both Goal 1 and 2. With the understanding that the word "distal" may apply to goal 1 based on the aforementioned explanation from USPTO, with the idea of the applicant being connected to or having a relationship with the RA.

However the word "remote" would apply to goal 2 as applicant is not connected to nor do the have a relationship with the RA nor any entity but rather a consumer simply needing to be remotely identity proofed for their trust credential.

So I hope this helps to clear up the contemplation. Look forward to your thoughts.


I have made some revisions to the Remote Electronic Identity Proofing Use Case to relieve implementation language and clarify actors taxonomy and roles.

A discovery and review of ISO/IEC WD1 29003 -- Information technology – Security techniques – Identity Proofing edited by Patrick Curry (UK), Anthony Nadalin (US) appear to have certain content that posit support for the remote electronic identity proofing use case. It cites the following:


IPV-Identity Proofing and Verification

IPVSP-Identity Proofing and Verification Service Provider"

I think these abbreviations addresses Tom Jones recommendation to appropriately identify the identity proofer.

Additional comments cite,

"Identity proofing and verification (IPV)

IPV has a number of processes, not all of which are sequential or essential for all applications. This is described further in Clause 10.

10 Identity Proofing and Verification

In reality, identity proofing and identity verification processes are not sequential but overlapping. Consequently, they are normally treated together, but recognising that proofing involves interacting with the applicant and verification does not.

10.2 Identity Proofing

The identity proofing requirements shall be more stringent, the higher the LoA. Also, the identity proofing process shall be more stringent for entities asserting or claiming an identity remotely (e.g., via an online channel) than locally (e.g., in-person with the RA).

Questioning the applicant by interview to assess their behaviour. Experience shows that in-person interviews are very effective in deterring fraud. All interviews should be witnessed or video recorded to High Definition video quality with clearly audible sound. The video record is to be stored and protected as a legal record and privacy data.

If the interview is done remotely:

 There shall be sufficient additional monitoring by trusted persons and/or trusted surveillance sensors and video recording to prevent fraud or misrepresentation for a given LoA.

 There shall be additional verification checks prior to the interview to establish the degree of risk associated with the applicant and the likelihood they will seek to subvert the interview."

The aforementioned and cited information clearly provides further considerations for remote electronic identity proofing and the anticipated NSTIC Ecosystem emerges and support is needed for individuals whom seek a trust credential for access to entities and services covered under the NSTIC Ecosystem.

'Comments From Use Case Ad Hoc Group':

Remote Electronic Identity Proofing Use Case Andrew to add description to actors, for those described as relying parties, explain what they are relying on. Andrew to change assumptions from consecutive sentences into separate bullets Andrew to modify content to refer to attributes instead of PII Ann will provide language for privacy considerations citing FIPPS and consumer protection bill of rights (and Scott will fix the template). Scott to provide privacy consideration language: "It is expected that attributes gathered during identity proofing are sensitive information and deserving of privacy protections."

Ann Racuya-Robbins

4.1 Privacy Considerations “The Remote Electronic Identity Proofing Use Case will utilize FIPPS and Consumer Privacy Bill of Rights for ongoing guidance as this Use Case is further developed.” (Add references to) FIPPS and CPBR

Tom Jones

“The Remote Electronic Identity Proofing Use Case will utilize FIPPS and Consumer Privacy Bill of Rights for ongoing guidance as this Use Case is further developed.”(Add references to) FIPPS and CPBR doesn't really work for a use case since a use case is not an implementation. The use case may reasonably recommend that specific actors follow the FIPPS and Consumer Privacy Bill of Rights for ongoing guidance.”(Add references to) FIPPS and CPBR