DRAFT PESC/InCommon "AdmitMe" Pilot Project

Discussion at Fall 2011 PESC Data Summit

Notes by: Doug Falk, Susan Hallenbeck, Susan McCrackin, and Arnie Miles

Where names are included, comments are always paraphrased! AdmitMe is a placeholder name and will be changed.

After a round of introductions of everyone in attendance, locally and on the phone, there was a overview of the “AdmitMe” Project.

Background and Summary:

[Background and Summary

../display/InCAdmissions/Streamlining+the+Admissions+Process+for+Prospects%2C+Service+Providers%2C+and+Higher-Education+Institutions]

Anne:              Want several goals to come out of this. 

A unique identifier for folks who are participating; also to higher ed organizations who are managing accounts, we want to know what you are doing now. There is a huge gap for higher ed to manage prospect identities, so this is a huge win for them.  Doing this right will help with matching.

Single sign-on for students.

 Third, increased LOA will be a big win for vendor partners.  Will be a bit win for everyone to have higher matching.

 A number of us were thinking this would be single sign-on, but we understand different players will come in at different time with different needs, so we understand this will have to be flexible and we will have to figure out how to do linking.  We’re trying to make this community driven, project driven, membership driven, but we want it to serve your needs.

Single Sign-On

SSO is a big issue – students may have 15-16 different websites and accounts they need to manage in the admission process.  Need to enable SSO so students can sign on once to access all info. However, some institutions may want local credentials as well.

Record Matching

Need for record matching – create unique identified to match student to all records (test scores, transcripts, etc.) This will be a huge win for higher education.

Levels of Assurance

Level of assurance: increased level of assurance (InCommon Silver or NIST LOA2, for example) would potentially increase the value of the credentials to all participants.

Will have a tech group, business group, and policy group on this issue

Would K12 be a separate group or should it be part of one of the other groups?

If vendors run an IDP first, what is the payoff for them?

  • Concerns for vendors about accepting identity management from other vendors (i.e., having ACT accept identity provided by College Board without requiring additional sign-in)
  • Will the second site attempt to monetize or appropriate account info from the first vendor?
  • Vendors – want to know how they will make money on this?

Business Group:

Business Group Discussion

David Moldoff has agreed to organize and hold regular teleconferences for a sub-group that will discuss the business needs and expectations of this project.

InCommon Partnership

  • Authentication is huge issue, esp. for large schools
  • Having records come in that are cross-correlated
  • Want to enable students to request things from vendors in the admissions process (able to request a transcript in the admission portal, etc.)
  • This group is very campus-focused – pairing Registrars and IT staff

 OpenID

There was some opposition to creating a centralized database. This will need to be further discussed.

Dave M.:         That might experience some political resistance.  When people realize they are tracked, people will resist that. 

Nate:               In Shibboleth, it is possible to use identifies as attributes.

Arnie:              Dave, what bothers you more – a name and a password is kept in a separate database or that a unique identifier is kept?

Dave M:          Both.

Arnie:              How do we get around the problem of a unique identifier?  We are dealing with vendors who are competitors and who are trusting each other right now.

Jeff:                 If all I’m doing is taking an idea and solving this piece of identification or I’m doing a validation of an identify, if we limit how much data can be passed in a transaction, then we can hedge against those security issues.  We would be creating an identity that states aren’t using.  We’re creating an id that is only created when the student signs up for a service.  We need to be careful not to mandate that every student must sign up for an AdmitMe account.  This could be a difficult issue with public opinion.

Education/Policy Group:

Ann West has agreed to organize and hold regular teleconferences for a sub-group that will discuss the needs of the education community. This group will also take on the roles of establishing policy requirements. This group will start with the InCommon Student group that is already created, with invitations to others to join in the discussion.

Need institutional buy-in, but need to focus on how to help the students get their business processes done – how are we helping students with the process?  How are we making it easier for students to navigate admissions application/aid processes?  Easier to apply as a transfer student?

Proof of Concept Goals:

[Proof of Concept Goals

../display/InCAdmissions/Proof+of+Concept+-+Phase+Descriptions]

Phase 1 – technical demonstration

Assumptions:

à      Will not be using live candidate data (not production data or live transactions)

à      Used as a tool to discuss architecture, workflow and business models

  • Whatever is developed is shared with business and policy groups for input and refinement
  • Admissions workgroup may have definitions and use cases that might be useful here
  • Prospect-driven relationship/functionality
  • Service Providers manage the account set up with AdmitMe behind the scenes based on the opt-in by the student
  • Prospect ease of use
    • Prospect SSO – can it be done?  How easily?
    • IdP of choice for student (student should be able to choose their identity provider)
    • Accommodate flexible plugging into the ‘identity’ network for service providers
    • Simulate LoA 1 registration authority
    • Authentication done by AdmitMe or Service Organization being accessed

Use Cases:

New User at a [Service Provider] Registration Authority:  Prospect accesses Service Organization 1 and gives them identity information to receive that service.  SO1, an approved registration authority for the AdmitMe Network, asks prospect to create account.  Prospect provides userid/password and clicks on Create AdmitMe Authentication Account.  Service Provider/RA communicates with AdmitMe in the background and does matching to ensure no duplications.  SO1/RA returns success re: new credentials.

Registered AdmitMe user Authentication (same service provider):  prospect can authenticate with AdmitMe to get into an AdmitMe Service Organization service. 

Existing AdmitMe User Attribute Aggregation: Prospect authenticates with AdmitMe credentials at SO2 and requests a new service. SO2 queries RA/SP1 for users identity information to populate their online form and user then supplies the remaining information required by SP2 to access the service.

Phase 2 – Technical Demonstration LoA 2

  • Need for a crosswalk or way to correlate identities across services providers to offer integrated services/matching
  • NIST LoA 2 Id Proofing

Where are students likely to be interacting with service providers first?

  • In some states, students in 7th/8th grade are taking PSAT or PLAN, so test companies may be first POC for these students in the college process
  • ConnectEDU and Naviance might also have information/interactions with students at a young age (6th/7th/8th grades)
  • Can we create a way to validate the students using a variety of touch points?  (i.e., Naviance student has been interacting with FC since 7th grade, takes PSAT in 8th grade – how to match and validate it’s the same student?)
  • Need to make sure students don’t end up with multiple accounts

At Level 0, any service provider could be a registration authority for AdmitMe

The comment was made that someone needs to do pre-validation of the student. Where the student first touches the system does not have to be decided as part of the creation of the prototype or production systems, because the system must be flexible enough to allow a large variety of registration authorities.

May need 2-factor authentication (esp. for financial aid) – need to be able to support this. SAML can support this, because SAML merely acts as the interface to query an Identity Store, the requirements for submitting credentials is handled prior to SAML.

Infrastructure for maintenance and support needs to be addressed – in a federated system, who is accountable to the student if there is a sign-in issue?  How do we share the load on this?

All members would need to agree to the same encryption standards, time-outs, etc.

Per ConnectEDU, if this system existed right now, ‘they would adopt it in a heartbeat’ because they are tired of having to create identity management processes. ConnectEDU is not alone, other participants have expressed an interest in getting out of the identity management issue.





  • No labels