Agenda:

Review plans for next 6 months:

  •  Identity Provider (IdP) 
    • Identity management
    • Account issue, password reset, etc, account checking to avoid duplicates
    • Report on Stress testing to find scaling factors
    • Make sure that the func and behavior that may be expected of the grown-up IdP is prototyped and tested to whatever extent possible
    • Other items not to violate scope creep rules
  • 2 or more service organizations demonstrating IS1 and IS2 separately
  • Pair-wise identifiers will be used initially to cover the more complex case, and additional stress testing will be necessary to address addition calls to the IdP.
  • (SP and IdP variably)
  • Identify what attributes should be kept in the CommIT IdP (first pass, for the prototype)
    -- fewest number of elements possible to uniquely identify a person for technical operation:
    -- CommIT username, UUID/entityID table, password, LOA2 data table or current state (tbd) 
    -- requirements for matching, de-duplication, contacts, linking
    -- password reset
    -- merging/purging (no mandate from CommIT to SPs for deleting data, but policy to be set independently): 
  • Attribute list candidates:  FN, LN, Sex, Addr, CITY, ST, ZIP, DOB, CEEB (HS), School City, School State, School ZIP, Student Type (First Year or Transfer), Email, Phone, Cell Phone, Parent1Name, Parent2Name, City of Birth, Other Contact Method, Preferred Contact Method
    -- requirements for desired functionality: 

Private

  •  
    • Public Authoritative Data Sources vs. Data Aggregators
  • Interface to IdP to demonstrate asserting and increasing/decreasing LOA, account vetting, etc.
  • IAt least one example of attribute aggregation
  • Account Linking
  • Identify identifier approach (as part of privacy arch), implement if possible

Commitments:  Rex Vokey MUSICCAS will volunteer to help with IS2 data transfer.  Hobsons and ConnectEDU will participate in both IS2 and data aggregation.  CommonApp and Hobsons will provide the demonstration of IS1. Nate Klingenstein will provide data sequence diagrams for aggregation with both single and pair-wise identifiers.  Multifactor research will be provided by Jeff Alderson.  Arnie, Ann and Vince will look at the best, smallest list of workable account attributes.  Charlie will talk to Heidi about elucidating privacy requirements.

Marketing:  

  • Clear delineation between Authentication and Data Sharing.  
  • Clear expectations for organizations considering joining.  
  • Preview data sharing as a future intent, within the context of participant control, business requirements, and strategy.  
  • Description of stages of the project.  
  • Representation from/for higher ed, including at least one Common App member and others.  Penn State, CMU, Georgetown, USC, Wisconsin, NC State. (Ann)  For October 2012 - online demo focusing Stage 1 with a minimal sneak preview of stage 2 functionality. 
  • Organization strategy (Ann, Charlie, Michael Sessa)
  • 2 minute scripted video or slide deck intro. (Arnie, Charlie and Ann with Rex and Jonathan)  Letters of commitment collected.  Support cases should be included for dupes, forgotten creds, etc.  
  • Explore giving presentations at appropriate conferences (presenters tbd)
  • Tim and Dave will redo the wireframes to pare down the data sharing preview, and highlight single-signon.  Website (Georgetown).
  • White paper to address all aspects of availability, reliability, security, SAS70

Decision Making:

  • Prototype
    • policy discussion framework to provide future input
    • advisory group to form from participation/sponsorship becomes steering committee in prep of pilot phase
    • combine business and higher ed calls
    • add monthly all-hands discussions periodically to sync parties
    • combine existing technical and policy writing into a more coherent, central source
    • enable wiki accounts - post instructions for signup
    • parking lot for outstanding issues
  • Pilot
    • steering committee comprises policy and tech participants
    • use existing InCommon agreement
    • SC is charged with choosing the IdP and issuing RFPs
    • 2 RFPs:  operations, support
    • is governance based on sponsorship?
    • Product Naming 

Funding:  

  • Privacy requirements research (Charlie, Heidi)
  • training
  • support
  • test resources
  • development
  • marketing / design
  • sources, entitlements and enforcement
  • product management / membership considerations
  • RFP could include stipulation of financial support
  • Explore Dept of Ed, Gates, Lumina funding
  • external funding may not be necessary to pilot

Long-term Roadmap:  to be continued on calls.

Pilot Stage: June 1, 2013

First Production Stage: August 1, 2013* Fed authentication and account linking

  • Identifier approach with privacy enforcements
  • Used by Common App and a handful of other HE partners
  • No LoA 2, matching, 

Prototype Phase 2:  (WHEN?)

Pilot Stage Phase 2: (WHEN?)

Second Production Stage: August 1, 2014 * Fed authentication

  • CommiT as a service** account linking
    • IdP
    • privacy and access management
    • user support
    • capable of LOA2
      -- proof/reproofing
  • Higher Ed and Business Services
  • Participation, Business Model and Certification Process in place
  • No labels