Assurance

["Michael R. Gettes" <>]

in case anyone else is making the same mistake i am…

i saw v102 and thought it was greater than v1.  well, it turns out v1 is 
dated dec 2011 which of course is much later than april 2006.  so the right 
document to view is

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

/mrg

On Aug 3, 2012, at 13:21, Michael R. Gettes wrote:

> okay, i'm an idiot.  ignore me - for now.  :-)
> 
> /mrg
> 
> On Aug 3, 2012, at 13:15, Michael R. Gettes wrote:
> 
>> Ann,
>> 
>> I am reading SP800-63V1_0_2 which has the first paragraph you cite in 
>> section 7 "Registration and Identity Proofing" on document page 19 and PDF 
>> page 29.  I am unable to locate the 2nd paragraph in part or whole in this 
>> version of SP800-63.  The first paragraph sheds lots of light on issues 
>> related to the CommIT project but I don't want to comment until we are all 
>> literally on the same page.
>> 
>> 1.0.2 is the latest rev of 800-63 and can be found at 
>> http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf 
>> linked from the main NIST SP site at 
>> http://csrc.nist.gov/publications/PubsSPs.html
>> 
>> Thanks.
>> 
>> /mrg
>> 
>> On Aug 3, 2012, at 12:43, Ann West wrote:
>> 
>>> All,
>>> 
>>> On the Implementers call on Wednesday, we talked about whether our 
>>> current id proofing models should be categorized as remote proofing or in 
>>> person proofing done remotely by another organization. 
>>> 
>>> One of the questions that arose is whether FICAM would allow 
>>> organizations independent from the IdPO (not the same legal entity) to 
>>> perform Id Proofing. 
>>> 
>>> In rereading 800-63-1 today, I suggest we all review their Registration 
>>> and Issuance Processes. I've included the primary sections below. How 
>>> would you answer our question from Wednesday?
>>> 
>>> Ann
>>> 
>>> 
>>> 
>>> 800-63-1
>>> 
>>> Page 27 Registration and Issuance Processes
>>> 
>>> The RA can be a part of the CSP, or the RA can be a separate and 
>>> independent entity; however, a trusted relationship always exists between 
>>> the RA and CSP. The RA or CSP maintain records of the registration. The 
>>> RA and CSP can provide services on behalf of an organization or may 
>>> provide services to the public. The processes and mechanisms available to 
>>> the RA for identity proofing may differ as a result. Where the RA 
>>> operates on behalf of an organization, the identity proofing process may 
>>> be able to leverage a preexisting relationship (e.g., the Applicant is an 
>>> employee or student). Where the RA provides services to the public, the 
>>> identity proofing process is generally limited to confirming publicly 
>>> available information and previously issued credentials.
>>> 
>>> And later in that section...
>>> 
>>> In models where the registration and identity proofing take place 
>>> separately from credential issuance, the CSP is responsible for verifying 
>>> that the credential is being issued to the same person who was identity 
>>> proofed by the RA. In this model, issuance must be strongly bound to 
>>> registration and identity proofing so that an Attacker cannot pose as a 
>>> newly registered Subscriber and attempt to collect a token/credential 
>>> meant for the actual Subscriber. This attack, and similar attacks, can be 
>>> thwarted by the methods described in Section 5.3.1 (below Table 3), which 
>>> describes which techniques are considered appropriate for establishing 
>>> the necessary binding at the various assurance levels.
>> 
>