Assurance

["Jones, Mark B" <>]

UTHealth is already doing the first part of what Nick is suggesting.  
http://www.uth.tmc.edu/netcenter/security/notary-process.htm

There are two documents linked at the above URL.  The most interesting is 
likely: http://www.uth.tmc.edu/netcenter/security/notary-verify.docx


-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Ann West
Sent: Thursday, May 31, 2012 8:56 AM
To: 

Subject: Re: [Assurance] Remote proofing?

Mark,

I think starting with Nick's blog as background is a good idea. For the 
details of the discussion, I'd check the list archive. 

InCommon Student and AACRAO did a survey of distance education admissions 
officers and wrote up the results in an article:
http://www.aacrao.org/Files/Publications/CUJ8703_WEB.pdf (See page 59.) 
There's a nice explanation of what remote proofing is and why it's necessary 
(thanks to Keith Hazelton) in addition to the results (which are depressing). 
This article might be a good place to start for definition of terms (and the 
state of current art and understanding).

Thoughts on other documents to include as background?

Ann

----- Original Message -----
> 
> Ann et al.:
> 
> I am kinda jumping in late.  Did the features/options
> of this thread get captured somewhere in the assurance
> wiki or is the best place to point folks who might
> want to attend the call Nick's blog post?
> 
> Just curious?
> 
> Mark
> 
> 
> ------------------------------------------
> Mark Rank - IAM Program Manager
> Middleware and Identity Management Group
> University Information Technology Services
> UW-Milwaukee
> Email: 
> 
> Phn:  414-229-3706
> ------------------------------------------
> 
> ----- Original Message -----
> From: "Ann West" 
> <>
> To: 
> 
> Sent: Wednesday, May 30, 2012 3:01:50 PM
> Subject: Re: [Assurance] Remote proofing?
> 
> Ok. Thanks all!
> 
> Those that are interested should join the Assurance call on Wednesday
> June 6, and we'll talk about next steps.
> 
> Ann
> 
> ----- Original Message -----
> 
> > I'm in.
> 
> > David
> 
> > "Michael R. Gettes" 
> > <>
> >  wrote:
> > > me 3
> > 
> 
> > > /mrg
> > 
> 
> > > On May 30, 2012, at 15:32, Roy, Nicholas S wrote:
> > 
> 
> > > > Me as well.
> > 
> > > >
> > 
> > > > Nick
> > 
> > > >
> > 
> > > > -----Original Message-----
> > 
> > > > From: 
> > > > 
> > > > [mailto:]
> > > >  On Behalf Of
> > > > Lovaas,Steven
> > 
> > > > Sent: Wednesday, May 30, 2012 2:30 PM
> > 
> > > > To: 
> > > > 
> > 
> > > > Subject: RE: [Assurance] Remote proofing?
> > 
> > > >
> > 
> > > > I'd also be interested in helping with this.
> > 
> > > >
> > 
> > > > Steve
> > 
> > > >
> > 
> > > >
> > 
> > > > ========================
> > 
> > > > Steven Lovaas
> > 
> > > > IT Security Manager
> > 
> > > > Colorado State University
> > 
> > > > 
> > 
> > > > 970-297-3707
> > 
> > > > ========================
> > 
> > > >
> > 
> > > >
> > 
> > > >
> > 
> > > > -----Original Message-----
> > 
> > > > From: 
> > > > 
> > 
> > > [mailto:]
> > >  On Behalf Of Bradner,
> > > Scott
> > 
> > > > Sent: Wednesday, May 30, 2012 1:18 PM
> > 
> > > > To: 
> > > > <>
> > 
> > > > Subject: Re: [Assurance] Remote proofing?
> > 
> > > >
> > 
> > > > I'm interested
> > 
> > > >
> > 
> > > > Scott
> > 
> > > >
> > 
> > > > Scott Bradner
> > 
> > > >
> > 
> > > > Harvard University Information Technology Innovation &
> > > > Architecture
> > 
> > > > +1 617 495 3864
> > 
> > > > 29 Oxford St., Room 407
> > 
> > > > Cambridge, MA 02138
> > 
> > > > www.harvard.edu/huit
> > 
> > > >
> > 
> > > >
> > 
> > > >
> > 
> > > >
> > 
> > > >
> > 
> > > > On May 30, 2012, at 3:10 PM, Ann West wrote:
> > 
> > > >
> > 
> > > >> If there's interest in convening a collaboration group to
> > > >> develop
> > > >> some recommendations on this topic, just let me know. Happy to
> > > >> help with the phone bridge, wiki page, doodle polls, etc.
> > 
> > > >>
> > 
> > > >> A good meaty thing to tackle, if you ask me.
> > 
> > > >>
> > 
> > > >>
> > 
> > > ;
> > 
> > > Ann
> > 
> > > >>
> > 
> > > >> Not saying dealing with people in other countries is not a
> > > >> problem,
> > 
> > > >> but I found this while trying to educate myself:
> > 
> > > >> http://travel.state.gov/law/judicial/judicial_2086.html
> > 
> > > >>
> > 
> > > >>
> > 
> > > >> From: 
> > > >> 
> > 
> > > >> [mailto:]
> > > >>  On Behalf Of Michael
> > > >> R.
> > > >> Gettes
> > 
> > > >> Sent: Wednesday, May 30, 2012 1:58 PM
> > 
> > > >> To: 
> > > >> <>
> > 
> > > >> Subject: Re: [Assurance] Remote proofing?
> > 
> > > >>
> > 
> > > >> aren't we all assuming a perfect world where the world we need
> > > >> is
> > > >> "good enough"?  and, have you tried to present an ID via video
> > > >> conf?  Frankly, it looks pretty good.  Additionally, I have
> > > >> the
> > > >> problem of dealing with people from other countries so Notary
> > > >> is
> > > >> problematic there.
> > 
> > > >>
> > 
> > > >> /mrg
> > 
> > > >>
> > 
> > > >> On May 30, 2012, at 14:54, Roy, Nicholas S wrote:
> > 
> > > >>
> > 
> > > >>
> > 
> > > >> This is a good point, Jacob- the validity of the documents
> > > >> would
> > > >> be harder to determine via video link.  I think this might be
> > > >> a
> > > >> benefit to having a notary look at the documents, if that's
> > > >> something they are trained to do.
> > 
> > > >>
> > 
> > > >> Nick
> > 
> > > >>
> > 
> > > >> From: 
> > > >> 
> > 
> > > >> [mailto:]
> > > >>  On Behalf Of Farmer,
> > > >> Jacob
> > 
> > > >> Sent: Wednesday, May 30, 2012 10:58 AM
> > 
> > > >> To: 
> > > >> 
> > 
> > > >> Subject: RE: [Assurance] Remote proofing?
> > 
> > > >>
> > 
> > > >> When it has come up at IU, one of the major concerns has been
> > > >> our
> > > >> ability to tell if the ID has been altered over the video
> > > >> link.
> > > >>  Granted, we are not likely to catch a good fake ID even if
> > > >>  it's
> > > >> presented in person, but it seems like we could very well miss
> > > >> a
> > > >> poorly altered ID over the video conferen
> > 
> > > ce
> > 
> > > link.
> > 
> > > >>
> > 
> > > >> Jacob
> > 
> > > >>
> > 
> > > >> From: 
> > > >> 
> > 
> > > >> [mailto:]
> > > >>  On Behalf Of David
> > > >> Walker
> > 
> > > >> Sent: Wednesday, May 30, 2012 11:53 AM
> > 
> > > >> To: 
> > > >> 
> > 
> > > >> Subject: Re: [Assurance] Remote proofing?
> > 
> > > >>
> > 
> > > >> I like this general approach.  It also raises the question of
> > > >> whether a video conference link should be considered remote or
> > > >> local.  Clearly, it's geographically remote, but the risks and
> > > >> the proofing process are much more like local proofing.
> > 
> > > >>
> > 
> > > >> Has anyone implemented identity proofing based on video
> > > >> conferencing?  I've heard it discussed before, but I'm not
> > > >> aware
> > > >> of actual implementations.
> > 
> > > >>
> > 
> > > >> David
> > 
> > > >>
> > 
> > > >> On Tue, 2012-05-29 at 19:11 +0000, Michael R. Gettes wrote:
> > 
> > > >>
> > 
> > > >> I've been mulling this over for some time.
> > 
> > > &
> > 
> > > gt;>
> > 
> > > >> Here are my thoughts on a Remote Proofing process we are now
> > > >> mulling over at CMU.
> > 
> > > >>
> > 
> > > >> There are parts in here to address some CMU problems of
> > > >> issuing
> > > >> 2nd-factor tokens - but you could take that out of the flow
> > > >> and
> > > >> it still is viable.
> > 
> > > >>
> > 
> > > >> The IDProof App has yet to be written.
> > 
> > > >>
> > 
> > > >> /mrg
> > 
> > > >>
> > 
> > > >> Version 1.0
> > 
> > > >>
> > 
> > > >> Actor = Person to be Identity-Proofed
> > 
> > > >> Proofer = Doh!  Could be any full-time CMU staff person
> > > >> appropriately authorized?  Could be Help Center staff?
> > 
> > > >>
> > 
> > > >> It is assumed the Actor has already been issued an Andrew ID -
> > > >> or
> > > >> must we define this process too?
> > 
> > > >>
> > 
> > > >> 0. Actor and Proofer agree upon method of Video Conference
> > > >> (FaceTime,
> > 
> > > >> Google Voice Video, Skype, others?)
> > 
> > > >>
> > 
> > > >> 1. Actor independently obtains physical FOB or downloads soft
> > > >> FOB
> > 
> > > >
> > 
> > > ;>
> > 
> > > >> 2. Proofer independently accesses ID-Proof Web App in a
> > > >> "Proofer"
> > > >> role
> > 
> > > >>
> > 
> > > >> 3. Proofer establishes VC with Actor.
> > 
> > > >> a.  It is most optimal if someone the Proofer knows is with
> > > >> the
> > > >> Actor as a "chain of custody".
> > 
> > > >>
> > 
> > > >> 4. Actor presents to Proofer Official Photo ID - holding it up
> > > >> to
> > > >> the camera.
> > 
> > > >> a.  Proofer verifies photo matches actor's face b.  Proofer
> > > >> records ID
> > 
> > > >> Type, Issuer, ID number into ID-Proof Web App c.  Actor
> > > >> provides
> > 
> > > >> AndrewID - Proofer validates AndrewID matches Actor d.
> > > >>  Possibility of
> > 
> > > >> obtaining digital photo capture of Actor in VC e.  If a
> > > >> "custodian"
> > 
> > > >> (see 3a) is present, record custodian AndrewID.
> > 
> > > >>
> > 
> > > >> 5. Process FOB
> > 
> > > >> a.  Proofer records Actor's FOB # and AndrewID into ID-Proof
> > > >> Web
> > > >> App
> > 
> > > >> b.  Proofer enables Actor's FOB
> > 
> > > >>
> > 
> > > >> 6. Actor verifies
> > 
> > > authentication and access a. Actor accesses ID-Proof
> > 
> > > >> Web App and login as normal user Actor authenticates using
> > > >> Shib
> > > >> SSO
> > 
> > > >> and then uses FOB authN on ID-Proof page.
> > 
> > > >> b. Actor is presented with a 6 character KEY c. Actor reads
> > > >> KEY
> > > >> to
> > 
> > > >> Proofer d. Proofer validates the Actor's KEY with KEY on
> > > >> Proofer's
> > 
> > > >> ID-Proof page.
> > 
> > > >> e. repeat a-d until success
> > 
> > > >>
> > 
> > > >> 7. Proofer approves Actor in ID-Proof Web App
> > 
> > > >>
> > 
> > > >> 8. End Video Conference
> > 
> > > >>
> > 
> > > >> 9. Proofer authorization
> > 
> > > >> a.  If Proofer has privilege to authorize then modify
> > > >> accordingly.
> > 
> > > >> b.  If not (9a) then Proofer notifies official authorizers
> > > >> ID-Proof steps completed and provides AndrewID and Name to
> > > >> Authorizers.  Authorizers modify accordingly.
> > 
> > > >>
> > 
> > > >> Done.
> > 
> > > >>
> > 
> > > >>
> > 
> > > >>
> > 
> > > >
> > 
>