Agenda:

1. Short intro to InCommon
2. Short into to CommIT
3. Discuss short-term project timeline goals. For example, a functional prototype of an IdP and a couple of SP's before the Fall meeting in Vancouver?  
   -- interoperability between providers is a focus, however modeling all possible behaviors is essential to encompass not only all the parties in play, but their evolution over time.
   -- IdP prototype should demonstrate LOA establishment and changes
4. What constitutes success with the prototype? What do we need to move to the next stage after the prototype?
5. Identifier constructs single vs. paired 
   -- a single identifier may be susceptible to correlate attack
   -- a pair-wise identifier requires central vetting and more complex implementation 
   -- pair-wise prevents unmediated data sharing because it must be controlled centrally
   -- we'll use a pair-wise approach for the prototype and can reduce requirements as necessary
6. Identify who, what, where the IdP prototype will happen. (Jeff Alderson and Patrick McFadin)  
   -- Stress testing, failover, high-availability, load balancing, and other aspects will be included in the prototype phase.  
   -- Lou D from Parchment will also participate in the prototype IdP stand-up.  
   -- Developer resources to code the IdP, as well as UAT will be needed, as well as Account registration, reset, group interfaces for updating the LOA, duplicate checking.
   -- SP functionality will be demonstrative of a successful connection in phase 1, but specific attribute transfer will be saved for phase 2
   -- At least one IS1 and one IS2 demonstration should be included
   -- a review of existing software approaches should be conducted prior to development of a fully proprietary suite.
7. Account Provisioning (wireframes, roles)
   -- 
8. Start talking about who's willing to stand up some SP's against our IdP. If CommonApp is willing to stand something, for example, the wire framing of their service will fall on them to do, at least beyond the account creating and linking phase. We will need some (2 or 3? the number is scalable based upon how much work the participant is willing to do) volunteer organizations to stand stuff up.
   -- IS2 prototyping will include Jeff Alderson, and should include a variety of organization types to be determined.  
   -- a brainstorming session to gather the best set of attributes and sources likely to be used will help to define the best scope of attribute transfer.
   -- define ingress and egress points and mechanisms, and ensure we can accommodate all flavors of transfer and user interaction will be necessary beyond attributes alone.
   -- 
9. Advanced wire frames, starting with the CommonApp and Penn State examples as time permits. 
10. Attribute aggregation (personal portfolio data)
    -- defining ingress and egress points for transfer requests and management
    -- "hello world" responses or XML will be used, for the prototype
    -- identifier mapping 
    -- logging of the reference ID, response time and the request type will be needed
    -- audit and reporting
    -- sequence diagram (Nate)
11. What kind of IdM do we need? Federated? Is that a done decision? Should we include account management (password reset stuff) features? Does the user interface have to look slick or just okay? what's the audience for the first prototype and how will it be used? 
    -- SAML 2.0 will be used
    -- is there an institution out there that has done a different implementation?  What do they recommend?
    -- Would Ellucian, Oracle or others be willing to participate?
12. 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, LOA data table
    -- requirements for matching, de-duplication, password reset:
    -- requirements for multifactor:
    -- requirements for desired functionality:
13. Performance related topics
    -- 60-100k logins in a 5 minute period are expected
    -- authentication, session management, attribute transmission all require communications outside the system
    -- Shib can be scaled linearly well in a VM environment
    -- benchmark stress testing will suggest baseline asset requirements
    -- quantifying latency in the base case and as it scales to real-world loads will be necessary
    -- reliability and failover on the back end are essential
    -- replication between IdPs - three approaches (HigherEd to be considered):  
    -- a centralized, third party provider, with SLA
    -- open bidding 
    -- a distributed model
14. Go through the wire frames that relate specifically to account creation and linking in an effort to clean them up in preparation for standing up an IdP and putting the pages up.
15. Marketing Considerations

Tabled Items

1. Roles beyond prototype
2. Deployment profile (Jeff Alderson?)
3. Identity assertions as established within the prototype stage