Kantara Initiative Identity Assurance WG Teleconference

Date and Time:

Date Wednesday, Oct 14, 2009
Time: 8:00 PDT | 11:00 EDT | 15:00 UTC

Attendees:

• Shin Adachi, NTT
• John Bradley
• Patrick Curry, Clarion Identity
• Mark Lizar, Identity Trust CIC
• Bob Pinheiro
• Colin Soutar, CSC
• Jeff Stollman
• Richard Trevorah, tScheme Limited
• Frank Villavicencio, NetStar-1
• David Wasley, Internet2
• Helen Hill, HIMSS
• Nigel Tedeschi, BT
• Jon Schoonmaker, Safe Bio-Pharma Assoc.

Apologies:

• John Tolbert, Boeing
• Rich Furr, Safe Bio-Pharma Assoc.

Agenda:

1. Roll call
2. Approve meeting notes from 9/30/09. Review and close up on any
pending action items.
3. Update on budget item requests
4. Briefing on recent "fish bowl" meeting revolving attribute-based
assurance - Jon Schoonmaker from SAFE-BioPharma
5. Update on the Kantarification of IAF documents, as well as ARB and
ICAM feedback for the IAF's SAC - Britta
6. Kick off Federation Operator rules and guidelines document - Rich Furr has volunteer to be the lead for this deliverable
7. Any Other Business

Minutes:

Roll call

Summary: Roll was called and quorum was achieved.

Action item review

Summary: The following action points remain outstanding:
Action Item: Britta to contact David T./GSA about participation in IAWG, noting that David is putting in a lot of time and work at the ARB level.
Action Item: Britta to contact Rich F. about a summary of his STORK research for the group (Patrick and Richard T are also heavily involved and offered to act in a liaison role), noting that STORK is looking as some very interesting, very tangible use cases right now.

Update on Budget:

Summary: Frank indicated IAWG will not have access to a funded editor moving forwards. However we still needed to address two deliverables:
Federation Operator Rules & Guidelines (FORGE) – Rich Furr had previous indicated he could take this role on.
Separate the IAF into the 5 constituent parts applying the Kantara document style -- Britta indicated she had volunteered for this role. (NOTE: these are currently available in our WORKING DRAFTS section.)

"Fish Bowl" meeting report back

Summary of comments:

• The meeting discussed the need for authorization profiles in addition to authentication.
• Discussions included the need to define schema / protocols to enable attribute request and response from attribute responders.
• Discussions identified the need to establish methods that allow service providers / relying parties to authenticate and trust attribute responders.
• Discussions included the need to address attribute value placement for identity authentication for physical access regards HSPD-12, FIPS 201 etc.
• DHS has identified the need for both on-line & off-line authorization decisions to be supported using issued credentials - this covers both identity and attributes from attribute responders. Off-line identity, authorization decisions are demonstrated by requirements from emergency services, FEMA & the use of the PIV & PIVi card. On-line decisions are demonstrated by SAML protocols etc. where attributes are used in conjunction with identity information to make authorization decisions.
• DHS concerned that solutions MUST be practical and implementable at state, county level etc. i.e. How does it work? How do we build it? How does it scale?
• Authorization decisions to be based on attributes both on-line and off-line; however the trust model is currently unclear.
• Meeting discussed a need for an agreed registry of attributes for authorization. Discussions indicated requirements for a registry should be established with standards groups.
• Regards usage of authorization attributes discussion covered where might leadership in this space come from? Names in the ring included the usual suspects: ICAM, Peter Alterman, Judy Spencer, others?
• It was noted that an attribute assurance framework was also signposted early within the Liberty Alliance activities however this work thread was parked to focus on identity assurance.
• It was indicated regards need for attribute responder assurance framework Booz Allan Hamilton covered similar ground 10 years previously for DoD. Judy Spencer maybe able to inform??
• It was noted that both DAS/ICAM has been looking at attribute responders and trust assurance requirements.
• AP Frank agreed to reach out to ICAM / Judy to see if their might information to share.

Kantarification of IAF documents, as well as ARB and ICAM feedback

Summary: Britta reported on the ICAM submission. Overall we have received very positive feedback from the ICAM team as to the completeness and applicability of our application.  During the first round of feedback, the ICAM team asked for more specifics with regards to the review of privacy requirements in the Trust Framework Provider Adoption Process (TFPAP).  These requirements, found in section 3.3, are:
 Trust Criteria Assessment – Assessment Team determines whether criteria applied by the Applicant to its member identity providers are comparable to ICAM criteria. Trust criteria assessment includes:
1. Technical and policy comparability based upon the Appendix A trust criteria;
2. Privacy policy comparability using the following criteria:
a. Opt In – Identity Provider must obtain positive confirmation from the End User before any End User information is transmitted to any government applications. The End User must be able to see each attribute that is to be transmitted as part of the Opt In process. Identity Provider should allow End Users to opt out of individual attributes for each transaction.
b. Minimalism – Identity Provider must transmit only those attributes that were explicitly requested by the RP application or required by the Federal profile. RP Application attribute requests must be consistent with the data contemplated in their Privacy Impact Assessment (PIA) as required by the E-Government Act of 2002.
c. Activity Tracking – Commercial Identity Provider must not disclose information on End User activities with the government to any party, or use the information for any purpose other than federated authentication. RP Application use of PII must be consistent with RP PIA as required by the E-Government Act of 2002.
d. Adequate Notice – Identity Provider must provide End Users with adequate notice regarding federated authentication. Adequate Notice includes a general description of the authentication event, any transaction(s) with the RP, the purpose of the transaction(s), and a description of any disclosure or transmission of PII to any party. Adequate Notice should be incorporated into the Opt In process.
e. Non Compulsory – As an alternative to 3rd-party identity providers, agencies should provide alternative access such that the disclosure of End User PII to commercial partners must not be a condition of access to any Federal service.
f. Termination – In the event an Identity Provider ceases to provide this service, the Provider shall continue to protect any sensitive data including PII.
The ARB reviewed this feedback and made some suggested recommendations to updates for the SAC, which are highlighted in the updated version of the SAC that has been circulated and is also in DRAFTS. The specific updates can be found online and are evident in the termination provisions and some additional service definition inclusions.
As such, the recommendation from the ARB to the IAWG for consideration is to 1) make the recommended updates as outlined above and 2)specifically for opt-in and informed consent, create a very lightweight appendix/profile be created specifically for the US Federal Government that directly addresses the specific opt-in requirements for attribute release to be applied.

Kick off – Federation Operator Rules and Guidelines (FORGE).

Summary: Frank indicated now that the initial release of the Identity Assurance Framework (IAF) is in place there is a need to kick off the FORGE activity that has been parked until now. Frank indicated there is a need for stewardship for the FORGE activity..
Richard Furr previously indicated he could lead on this deliverable.
Frank indicated there was a need to move to weekly calls to prioritize and progress the FORGE document.
It was discussed the FORGE framework should address the Core Liberty / Kantara IAF, the FORGE trust framework and jurisdiction specific requirements. It was briefly discuss that the ICAM requirement for a privacy profile could be covered by a jurisdiction element of the FORGE although there may be issues comparing jurisdiction profiles of region #1 with those of region #2? It was note Richard Trevorah had dealt with similar issues regards tScheme deployment, and there maybe words of wisdom to be shared.
Richard Trevorah volunteered to help drive the completion of IAF edits into the updated, Kantara-ized IAF documents driving these to a closure.