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

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


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