[WG-P3] Draft Statement of Project Scope for IAF-1800

Mark Lizar mark at smartspecies.com
Tue Mar 22 06:26:15 EDT 2011


Ben,

Excellent way to move the conversation forward.  This will be added to  
our next Agenda.   (I hope we can have some feedback from our members  
before this meeting)

I like the approach and welcome the discussion of  a cross Kantara WG  
case study in Health Care Identity, I think its very appropriate.

Thank You,


On 21 Mar 2011, at 21:50, 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 Model
> Background:  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)
> Direct: 1-801-701-9678
> 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
> http://kantarainitiative.org/mailman/listinfo/wg-p3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-p3/attachments/20110322/7a4a1de4/attachment.html 


More information about the WG-P3 mailing list