[WG-P3] Draft Statement of Project Scope for IAF-1800
colin_wallis at hotmail.com
Wed Mar 23 23:45:50 EDT 2011
I thought it was a good start.
What I wasn't so sure of, was to what extent it was informed by current Federation operating agreements, such as the higher ed ones like InCommon, Haka, Switch, (JITSC? in the UK) etc who all have published fed ops procedures that give a good feel for the range of areas to be agreed by the federation.
Also years ago, SUN did a checklist for BIPAC (Darryl Schull, where are you when we need you..:-))
Armed with those, I think the job will be a lot easier than it looks right now.
From: dervlaoreilly at me.com
To: ben at digicert.com
Date: Mon, 21 Mar 2011 15:14:27 -0700
CC: Wg-healthidassurance at kantarainitiative.org; wg-idassurance at kantarainitiative.org; wg-p3 at kantarainitiative.org; WG-FI at kantarainitiative.org
Subject: Re: [WG-P3] Draft Statement of Project Scope for IAF-1800
I've sent over to the Healthcare Identity Assurance Work group for input and feedback.
Program ManagerKantara Initiative+1 415 731 4487 business
+1 415 948 3650 mobile+1 509 757 4487 faxdervla[at]kantarainitiative[dot]orghttp://www.kantarainitiative.orgSubscribe to the Kantara Initiative newsletter
On Mar 21, 2011, at 2:50 PM, Ben Wilson wrote:As discussed on a recent IAWG telephone call, could someone forward this to the Healthcare Identity Assurance Workgroup to get their feedback? As I’ve stated previously, I don’t favor any particular approach over another. I’m just putting this out here to move the discussion forward. Draft Statement of Project Scope to develop a Three-Part IAF-1800 and to Create Parts 2 and 3 using Healthcare as a ModelBackground: The document roadmap for the Kantara Initiative’s Identity Assurance Framework references document IAF-1800 – Relying Party Guidelines. While working on the first draft of the document, it has become clear that this document must be considered from multiple perspectives—the relying party’s perspective, as well as others’ perspectives (i.e. meeting the Trust Framework’s expectations, including those of Subjects and Identity Providers, “IdPs”). Furthermore, it was brought out in discussions among members of the IAWG that the phrase “relying party” is, at best, ambiguous in the context of the IAF. For instance, the subject of the data (Subject, Principal, Subscriber, etc.) becomes a relying party when they submit information to a service provider that authenticates them based on the identity assertion provided by an Identity Provider. Therefore, it is proposed to separate the Relying Party Guidelines into three parts: Part 1 – General Guidelines for Identity Assertion Recipients; Part 2 – Risk Assessment Framework for Identity Assertion Recipients and Data Handlers; and Part 3 – Data Protection Guidelines for Data Handlers. Part 1 - In Part 1, the Guidelines would contain a generalized set of expectations between relying parties, acting in the role of identity assertion recipients, and IdPs, As background for discussion of relying party obligations are the logistical services provided by the IdP. These include communications mechanisms, timing of maintenance, time synchronization, notification of downtime, application software patching, configuration management, and other similar activities that could potentially impact connectivity land the timely delivery of identity assertions. With this background, other participants will have expectations of recipient relying parties, including that they will: (a) conduct their own assessment of the level of credential required and select the appropriate technology and level of assurance (LoA) based on documentation of acceptable risk; (b) implement systems that properly process information (and obtain FISMA / ISO 27001 certification or accreditation for such relying party systems, where appropriate); (c) verify the credential in accordance with the policies and technological specifications of the credential / assertion providing system; and (d) rely upon and act reasonably in the context of the transaction contemplated. General data use risk assessment and LoA selection criteria will be reviewed in Part 2, as discussed in the next paragraph. Finally, data protection requirements and privacy protections would be discussed in Part 3, discussed below. Part 2 - Another aspect of the identity assertion framework that could be discussed is relying party risk assessment for the type or LoA of identity credential used, such as that discussed in M04-04. A discussion of applicable rules might distinguish between contract-based and other types of legal frameworks. For instance, under what circumstances do relying parties accept the risk of assertions made by identity providers? What are the consequences when the identity provider lives up to LoA and SLA requirements versus when they do not? A relying party would need to manage the risk beyond the LoA offered. All of the parties need to understand the risk allocation framework. This is likely driven by the intended use of the identity information, so industry-specific approaches may be needed. Alternatively, this entire discussion could be off-loaded to a legal-specific document that presents the risk allocation and legal liability model. (In other words, Part 2 could be removed from this Statement of Scope and placed in a separate scope statement.)Part 3 – Part 3 would contain guidelines for protecting the data being handled. Many standards already exist for the handling of personal data. These have been canonized in various laws, like the EU Data Protection Directive (public, personal and sensitive personally identifiable information - PII), or in government/police/military communities (like restricted, confidential, secret and top secret). User-centric privacy concerns will need to be addressed, as will data handling beyond PII for other types of sensitive data (e.g. security / emergency evacuation plans, etc.). Similarly, this entire discussion could be off-loaded to a privacy-specific document that reviews privacy considerations separately, and this suggested Part 3 could be removed and a separate Statement of Scope could be created for this aspect of the relying party relationship. Healthcare as an Example It is assumed that a subject matter neutral approach can be used for the drafting of Part 1. However, it may be illustrative to use a particular subject matter to give form to Parts 2 and 3. It is proposed that the healthcare industry be used to create guidelines for a framework to be used by members of the Kantara Initiative in the other data communities, like those identified in the previous paragraph. Members of the IAWG are aware of the work of the Healthcare Identity Assurance and Privacy and Public Policy Workgroups and believe that a coordinated effort will help develop an initial framework for Parts 2 and 3 using healthcare as a use case. The proposed scope for creating this healthcare example for Part 3, a “reference instantiation” would including an overview of the high-level expectations that patients, treating physicians, and covered entities have of business associates and other “partners” in the healthcare delivery and payment process. Resources for the document will include standard Business Associate Agreements, Data Use and Reciprocal Support Agreements (DURSAs), and work product and contributions of various community stakeholders such as the ONC’s Privacy and Security Tiger Team, SAFE-Biopharma, Canada, Austria, the UK, and other KI participant representatives. One important objective of this initial project will be to avoid “re-creating the wheel” or merely repeating standards, while still writing something for the Kantara community to use without getting bogged down into a detailed security and privacy framework.Sincerely, Benjamin T. Wilson, JD CISSP
General Counsel and SVP Industry Relations
DigiCert, Inc.<image001.gif>Online: www.DigiCert.com
Email: ben at digicert.com
Toll Free: 1-800-896-7973 (US & Canada)
Fax: 1-866-842-0223 (Toll Free if calling from the US or Canada)The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Thank You _______________________________________________
WG-P3 mailing list
WG-P3 at kantarainitiative.org
WG-P3 mailing list
WG-P3 at kantarainitiative.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the WG-P3