InCommon Federation Discussions About Online Student Services

[Ann West <>]

Nancy et al,

I have updated the notes to reflect this clarification. See
https://spaces.internet2.edu/display/InCCollaborate/25+July+2008

Ann

Krogh, Nancy wrote:
> Bob, 
>
> I'll try to clarify one thing from the notes.  When I was referring to
> 3-10 as the range with 5 as a mid-point I was referencing policies about
> the how small a cell size should be before redacting information to
> protect individual identities.  It doesn't relate to how many sources we
> have to prove an individual's identity.  Most institutions have a policy
> like this when supplying aggregated information for public records
> requests or other data tables.  It would not apply when passing along an
> individual identity because we --or the student-- would have already
> approved sharing the information.   I can't even remember why this came
> up, but I wanted to be sure that I didn't leave a mix-up about what
> policies we were discussing.  
>
> That is a good catch, Bob.  Perhaps we can suggest a clarification to
> the minutes at our Friday meeting.  They are clear to me, but of course
> I am reading them in the context of the discussion I remembered.  
>
> Thanks, Nancy  
>
> -----Original Message-----
> From: RL 'Bob' Morgan [] 
> Sent: Tuesday, August 05, 2008 1:28 PM
> To: InC-Student
> Subject: Re: [InC-Student] Notes from July 25
>
>
> Sounds like it was a productive call.  Let me follow up on a couple of 
> points.
>
>   
> > 2) If it's AACRAO then, who would develop IdM-related recommendations?
> >     
>
>   
> > Nancy mentioned the AACRAO Information Systems and Technology
> >     
> Committee, 
>   
> > but thought that the IdM scope is too big (or too specific) for her 
> > group. Joanne mentioned that a task force should be assembled to work
> >     
> on 
>   
> > shared IdM issues. It should have campus members from the registrar/IT
> >     
>
>   
> > areas and be a traveling forum to help both communities come together.
> >     
>
>   
> > Joanne then proposed that this InC-Student group be repurposed/charged
> >     
>
>   
> > with this task, since we have the right folks on it already. We would 
> > just need the blessing of AACRAO.
> >     
>
> This sounds like a great idea to me.  InCommon has been a good venue for
>
> those of us doing identity management to engage a number of communities,
>
> including the AACRAO community (also libraries, research administration,
>
> government, learning management, etc).  It seems fine to me for those 
> engagements not to be limited onlyto federation cases.
>
>   
> > The group would use federated identity as a driver to inspire campuses
> >     
> to 
>   
> > adopt standard practices. In this light, our primary tasks might be:
> >   a) review existing federal (higher education?) documents/practices
> >     
> and 
>   
> > promulgate them in the AACRAO community and
> >   b) identify gaps that are of most concern that we should consider.
> >     
> One 
>   
> > example that came up is developing strategies for  resolving duplicate
> >     
>
>   
> > identities; this topic is not germane to federating but is certainly
> >     
> sticky 
>   
> > for campus operations.
> >     
>
> Actually federation has a number of interactions with the duplicate 
> identity problem.  In one way it makes the problem worse, of course,
> since 
> there will likely be more places someone can be "from".  In other ways
> it 
> may make things better, as users are becoming more familiar with the 
> notion of merging multiple accounts, since it happens on the Internet
> all 
> the time now, making user self-matching more feasible as a duplicate 
> reduction technique.
>
>   
> > - Enrollment verification and vendors interested in using/supplying
> >     
> this 
>   
> > service. MyIdentit-e (https://www.myidentit-e.com/) is a enrollment 
> > verification service offered by Douglas Stewart Company and just
> >     
> joined 
>   
> > the InCommon Federation. From the website, it looks like students send
> >     
>
>   
> > their information to this service, and it would in turn verify their 
> > status to vendors (using SAML/Shib?) and enable them to get
> >     
> "discounted 
>   
> > products." Student Universe (http://www.studentuniverse.com) is an 
> > example of the type of discount service that is the target for 
> > MyIdentit-e.
> >     
>
> Note that studentsonly.com (which serves studentuniverse.com) has been a
>
> member of InCommon for quite a while.  We've been working with them at
> UW 
> to set them up to rely on student-status verification via federated 
> signon.  The holdup as usual was getting a legal agreement in place.  I 
> think we're just about ready to go.  We're hoping that our agreement and
>
> setup can be a model for other campuses and other vendors for this use 
> case.
>
>   
> > What proves "student-ness" in this context? And does the eduPerson 
> > Schema have the right attributes?
> >     
>
> The university remains authoritative, we're just changing the means of 
> getting the info to the service.  Yes, eduPersonScopedAffiliation works 
> fine, ie it has a defined "student" value that many sites are using.
>
>   
> > How many attributes does it take to point to identity? Nancy reported
> >     
> a 
>   
> > recent conference where schools used 3-10 pieces of information, but
> >     
> the 
>   
> > mean was 5.  We'd want to be cognizant about when we cross over from
> >     
> the 
>   
> > point of verifying enrollment to supplying identity.
> >     
>
> I'm not sure what "supplying identity" means exactly, but the 
> cheap-tickets-for-students case needs an assertion of student status,
> and 
> in the case of studentsonly.com, it also needs the student's name, since
>
> the airline requirement is that the name on the ticket match the name of
>
> the person who has the verified status.  So that's what they'll be
> getting 
> from us.
>
>   - RL "Bob"
>
>