This document outlines the Higher Education Functional Requirements for Stage One Release of the CommIT Collaborative.

v.02 June 22, 2012

Outsource Authentication and Account Management for Prospects

  1. Requirement: Support federated authentication and accept federated credentials from the CommIT IdP(s) 
    1. For prospects with a CommIT account, HE assumes the following services will be in place:
      1. electronic credential assignment or distribution. 
      2. authentication service.
      3. password reset or password management services. 
      4. primary support for authentication/login issue. Federated support will require some interaction between HE SP operators and CommIT support. 
    2. User Experience
      1. When prospect accesses service, he/she is given a choice to login in with CommIT account or create a new CommIT account, campus will redirect to CommIT for authentication or account creation. 
    3. Identifier
      1. Once authenticated, CommIT will pass the CommIT Identifier to the campus for record look up. (See matching for questions on what to do with a new account or with a person with no CommIT id on file.)
    4. Risk
      1. Level of Assurance 1 minimum requirement (but can we easily achieve LoA 1? Do current interactions with prospects achieve LoA 1? Is there still value if we're unable to deliver LoA 1 initially?)
  2. Questions
    1. Is account linking a requirement? Does HE want the option to just link a CommIT account to a new or existing HE account?
    2. Would we like to request initial higher education participants to require all prospects to have a CommIT account? This is desirable because, in order to support local accounts, that HE partner must run a parallel account management and authn system and expose both options to users. This would result in a number of duplicates and a significant amount of user confusion. In the future, HE partners who want to operate parallel account management systems will be responsible for handling duplicates and account linking because, in the case of duplicates or other user confusion, it will be the organization interacting with the user and the only organization with even partial access to both user records.
      1. Can a prospect get a CommIT account on the HE admissions site?
    3. Does one get a CommIT account from partners, from the CommIT website or both? How transparent is the CommiT service? We think that the CommIT IdP must be solely responsible for the creation of accounts, but users may initiate account creation directly themselves or passed into the CommIT account creation process by partners. In the event the user is passed in by partners, the branding and user experience should recognize that partner's needs while still providing as consistent and common a user experience as possible.
  3. Who does what?
    1. HE and Partners
      1. Run a federated service provider 
      2. Be able to accept and use CommIT identifiers
      3. Change login process to include CommIT. 
      4. Report suspected duplicate or bad records to the CommIT IdP
    2. CommIT manages
      1. Account creation, matching to maintain service integrity, management, troubleshooting
      2. Authentication service
      3. Password life cycle
      4. Support, documentation, public-facing website
      5. Respond to reports of suspected duplicate or bad records reported by partners

Enabling Matching of Student Records with CommIT Identifier

  1. Requirement: Match the person accessing the admissions site (fed authentication) with third-party information received.
    1. CommIT Identifier (Added 8/17)
      1. Persistent
        1. If same identifier across all CommIT members
          1. could be used as an index into all services
      2. Non-reassignable
      3. Usage Policy
        1. Transparency
          1. Notification of Policy
          2. Notification of record changes (merging of records etc)
        2. Privacy
          1. Services require opt-in
          2. Services require explicit consent from the user to transfer or access data held by another service provider
        3. Related questions
          1. Does this single identifier create dramatic risks?
          2. Could be the target of attack.
            1. Compromising a service providers implementation of CommIT might be more of an issue.
            2. If we have a common technology architecture and breach processes, we can mitigate further risks if the compromised service provider a) knows about the breach and b) notifies CommIT members about it.
    2. Include CommIT identifier when sending prospect information to HE
      1. Batch 
      2. Single individual
    3. Each prospect should have only one CommIT identifier
    4. Enable HE org to match the ID an existing prospect (with an ID from the HE) who subsequently obtains a CommIT identifier
  2. Who does what? ("Partners" in this context, includes business partners and other HE institutions)
    1. HE process incoming files from partners (including business partners and other HE institutions) with CommIT ids
      1. Will HE send information to other partners and need to include CommIT ids?
    2. Partners need to include CommIT in their feeds to HE
      1. Match their holdings to CommIT
      2. What if the person has a CommIT account and hasn't established a relationship with partner? 
        1. Does partner need to determine if the person has a CommIT id?
    3. CommIT 
      1. Mange assignment, operations and change process of identifier for each individual
      2. Minimize identifier mismatches as much as is feasible
        1. One person with two or more identifiers
        2. Two or more people with one identifier
      3. Does CommIT need to run a matching service to determine if the individual in the partner db has a CommIT id?
        1. Or a lookup service?
  3. Questions
    1. If the prospect has never accessed the HE site before and does not have a CommIT ID on file, does HE need more information from CommIT to create a local database entry to do local matching for data that's not linked with a CommIT ID?
    2. Are CommIT IDs stored locally? Assume yes.
    3. CMU Use case question. What does this mean?
      1. If the CommonApp ID # cannot be supplied, then the CommIT identity needs to be added to the CommonApp/CMU feed so CMU can match up the applicant in the admissions system.
    4. What's the balance between matching and privacy? Do we enable cross-correlation with a single identifier? Or is CommIT a cross-walking service that is subject user privacy controls?
    5. Is there a way for this system to handle special cases (someone wanting to remain anonymous in the admissions process, for instance)?
      1. can a single individual have multiple CommIT identifiers that are somehow linked?
      2. or, can a single individual have one CommIT identifier, but create aliases that point to that identifier?

Enable the Use of CommIT Credentials to Establish Permanent Campus Credentials

  1. Requirement: Use CommIT federated services to authenticate and establish identity to assign HE's permanent credentials
    1. See Outsource Authenticaiton Above
    2. Risk
      1. Level of Assurance 1 minimum requirement?
  1. Questions
    1. Account linking required?
    2. CommIT id to HE?
    3. Only authentication?

Enable Forms Completion

Enable Stronger Credential Access at Level of Assurance 2 

Business Requirements

Recognizable Memorable Logo

Common User Experience for students applying to HE?

Partners Involved

  • Penn State - ACT/SAT?
  • CMU - CommonApp?
  • No labels