InCommon Federation Discussions About Online Student Services

["Krogh, Nancy" <>]

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"