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

Ben Wilson ben at digicert.com
Mon Mar 21 17:50:23 EDT 2011

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



Benjamin T. Wilson, JD CISSP 
General Counsel and SVP Industry Relations
DigiCert, Inc.

 <http://www.digicert.com/> Visit DigiCert.com

Online:  <http://www.digicert.com/> www.DigiCert.com
Email:  <mailto:ben at digicert.com> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-p3/attachments/20110321/a599b99f/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2926 bytes
Desc: not available
Url : http://kantarainitiative.org/pipermail/wg-p3/attachments/20110321/a599b99f/attachment-0001.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5403 bytes
Desc: not available
Url : http://kantarainitiative.org/pipermail/wg-p3/attachments/20110321/a599b99f/attachment-0001.bin 

More information about the WG-P3 mailing list