Assurance

["Jones, Mark B" <>]

I think I’m missing something.  What is considered “the time of registration” for ‘remote’ identity proofing?

The way I read 800-63 I don’t see how it even applies to remote proofing.  My assumptions are that the applicant would communicate the required information to the RA; the RA would take however many minutes, hours, or days required to verify the information; and then the RA would issue the credential in a manner that confirms the address of record (possibly using regular mail).

 

I’m not seeing the requirement “to validate the documents at registration time” in the 800-63 language.

 

From: [mailto:] On Behalf Of Roy, Nicholas S
Sent: Wednesday, August 08, 2012 11:11 AM
To:
Subject: RE: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing Approaches

 

Table 3 on page 33 for remote proofing:

 

“RA inspects both ID number and account

number supplied by Applicant (e.g., for correct

number of digits). Verifies information provided

by Applicant including ID number OR account

number through record checks either with the

applicable agency or institution or through credit

bureaus or similar databases, and confirms that:

name, DoB, address and other personal

information in records are on balance consistent

with the application and sufficient to identify a

unique individual.  For utility account numbers,

confirmation shall be performed by verifying

knowledge of recent account activity.  (This

technique may also be applied to some financial

accounts.)”

 

http://csrc.nist.gov/publications/nistpubs/800-63-1/SP-800-63-1.pdf

 

From: [] On Behalf Of Jones, Mark B
Sent: Wednesday, August 08, 2012 10:37 AM
To:
Subject: RE: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing Approaches

 

Do you have 800-63 document references for some of the things that are left out of the IAP?  I tried to find the requirement to validate documents at the time of registration and can’t find it.  I have not stumbled on any obvious omissions.

 

From: On Behalf Of Roy, Nicholas S
Sent: Wednesday, August 08, 2012 8:49 AM
To:
Subject: RE: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing Approaches

 

From what I can deduce (perhaps completely inaccurately, but it “feels” like this to me, and I’ve been a reviewer on a couple revisions of the IAP) about the drafting process , there is a strong reason for not documenting or explicitly stating some of the things that are “left out” of the IAP/IAAF, things which exist in 800-63.  I think the requirement to validate the documents at registration time is one of these things.  I think nearly every omission of this type was made in the interest of making it possible to achieve Silver in a typical higher education setting.  Almost all of the “omissions” that make things less clear in the InCommon assurance documents also make them less proscriptive in a way that makes them easier to achieve in the real world.  Some people suggest this makes the IAPs “weaker” than 800-63.  I’d argue it makes them more useful in that they can actually be implemented.

 

Nick

 

From: [] On Behalf Of Ann West
Sent: Tuesday, August 07, 2012 10:00 AM
To:
Subject: Re: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing Approaches

 

Well Nick is correct. Silver is not a carbon copy of 800-63. It contains additional information about InCommon's trust model, certification requirements, HE comparable solutions (See 4.2.2.4.1 Existing Relationship for instance), etc. 

 

However, you're correct too, Mark, in the case of the identity proofing requirements. Silver is comparable and in some cases, uses the same language. 800-63-1 does provide more background about the process, however, that might be useful to folks, which is why we strongly recommend it as prerequisite reading and as a reference. 

 

Ann

---

Where did "Silver is not 800-63 level 2, Silver is Silver" come from?  I’m confused why people seem to want to distance Silver from 800-63.

 

From what I read, 800-63 level 2 is exactly what Silver is with respect to identity proofing and credential issuance.

 

“InCommon Bronze and Silver are intended to be compatible with US federal government Identity, Credential, and Access Management (ICAM) Trust Framework Provider Adoption Process (TFPAP) Levels of Assurance 1 and 2.”

http://www.incommon.org/docs/assurance/IAP_V1.1.pdf

 

and

 

800-63 is a core ICAM document.  http://www.idmanagement.gov/pages.cfm/page/ICAM

 

If that is not enough…

 

Sections §4.2.2.4.2 and §4.2.2.4.3 of the IAP describing ‘in-person’ and ‘remote’ proofing are taken verbatim from the 800-63 table that describes “Identity Proofing Requirements” for NIST level 2.  http://csrc.nist.gov/publications/nistpubs/800-63-1/SP-800-63-1.pdf

 

When we are discussing identity proofing and credential issuance for Silver we are talking 800-63.

 

 

From:
Sent: Monday, August 06, 2012 5:01 PM
To: Jones, Mark B
Subject: [confluence] InC-Assurance > Remote-Proofing Approaches

 

Remote-Proofing Approaches

Page comment added by

 

I got some feedback from the Big Ten auditor community.  Their feedback was (generalized):

1) The notary approach might work

2) They don't like the video approach, but did not give specific reasons why

3) They think the eVerify process used for I9 stuff in HR processes is good enough to use for proofing (not remote, really, but OK I think this is good news for existing relationship stuff)

4) Quote:

"I don't know how InCommon relates to NIST 800-63, but 800-63 seems clearer.  It says that remote proofing for Level 2 or 3 requires validation of the gov't ID and/or financial acct, plus address validation.  The latter is not a substitute for the former."

To me that says if you take this to be 800-63 rules, then you also need to validate the ID at LoA2/Silver.  But then again, "Silver is not 800-63 level 2, Silver is Silver."

Stop watching page | Change email notification preferences

View Online | Reply To This