[WG-IDAssurance] Draft Project Scope for Healthcare Test Case

Mon Mar 21 10:51:54 EDT 2011

My comments are included inline below.  

Sincerely,

Myisha

Myisha Frazier-McElveen

Practice Manager, Identity Management

703-766-6203 (O) | 240-751-7780 (C)  

myisha.frazier-mcelveen at truestonefed.com
<mailto:myisha.frazier-mcelveen at truestonefed.com>  

Flexible Solutions, Proven Results
<http://www.truestonefed.com/IAMgmt/EnterpriseIAM.php> 

http://www.truestonefed.com/IAMgmt/EnterpriseIAM.php
<http://www.truestonefed.com/IAMgmt/EnterpriseIAM.php> 

From: wg-idassurance-bounces at kantarainitiative.org
[mailto:wg-idassurance-bounces at kantarainitiative.org] On Behalf Of Rich
Furr
Sent: Monday, March 21, 2011 9:40 AM
To: Ben Wilson; 'IA WG'
Subject: Re: [WG-IDAssurance] Draft Project Scope for Healthcare Test
Case

A suggestion:

1.     "policies and" inserted since it is not only technical specs that
support assertions but also the policies, especially those related to
identity verification and credential management that support various
levels of authentication assurance.  RPs must be able to rely on the
fact that the credentials are managed according to a stated set of
policies (preferably cross certified or certified within the federation)
which they can trust.,

Rich Furr

Head Global Regulatory Affairs and Compliance 

New Office:  980-236-7576

Cell: 201-220-0160

From: wg-idassurance-bounces at kantarainitiative.org
[mailto:wg-idassurance-bounces at kantarainitiative.org] On Behalf Of Ben
Wilson
Sent: Monday, March 21, 2011 1:13 AM
To: 'IA WG'
Subject: [WG-IDAssurance] Draft Project Scope for Healthcare Test Case

Before we send this out to a larger group, does anyone want to edit it?
I am ambivalent about whether the larger part of the following is an
IAWG or P3 WG task.  In other words, to limit the scope of the IAF-1800
and deliver it sooner, we could limit the scope of that document to
"Part 1" identified below.

Project Scope for Healthcare-based Reference Instantiation to develop
Part 2 of IAF-1800

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, and others' perspectives
(meeting the Trust Framework's expectations, including those of Subjects
and Identity Providers).   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 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 two parts:  Part 1 - Guidelines for Identity
Assertion Recipients; and Part 2 - Guidelines for Data Handlers.  

In Part 1, the Guidelines would contain a generalized set of
expectations of relying parties acting in the role of identity assertion
recipients.  

A discussion of applicable rules might distinguish between
contract-based and other types of legal systems.  For instance, under
what circumstances do relying parties agree to hold identity providers
harmless?  

MFM - Are we proposing here that the RP Guidelines contain a discussion
of contract-based and other types of legal systems?  I would suggest
that a discussion around liability be in a legal portion of a Trust
Framework model.  

Expectations would include duties to:  (a) verify the credential in
accordance with the policies and technological specifications of the
credential / assertion providing system; and (b) rely upon and act
reasonably in the context of the transaction contemplated.  Data
protection requirements and privacy protections would not be discussed
in Part 1.   It is assumed that relying party risk assessment for the
type or LoA of identity credential used, such as that discussed in
M04-04, is out of scope.  

MFM - I would think that it would be perfectly reasonable to address a
risk assessment criteria given that would be how an RP determines the
type of and level of IdP they would rely on.  Furthermore, an IdP would
want to know that the level of credential required was based on a well
thought out assessment and not an arbitrary selection of technology
based on a perceived and not actually documented level of risk.

Other things that I think we would want to address in an RP guidelines
doc are logistical communications between the IdP and RP, such as:

Timing of maintenance,

Notification of Down time

Application of software patches

Configuration Management type activites that could potentially impact
connectivity (especially for assertion based connections)

Time Synchronization

Not sure if these belong in here or an operational type document but
these are things that an IdP would be concerned about as it does impact
the connectivity between the RP and IdP.   The other thing to keep in
mind is that in the Federal space, RP applications are required to
undergo an assessment in compliance with FISMA.  I believe the
comparable requirement in the private sector would be an ISO 27001
certification.  Would it not behove us to put something in the document
recommending some sort of certification whether FISMA / ISO 27001?

Part 2 would contain guidelines for protecting the personal 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-other types of sensitive data (e.g. security /
emergency evacuation plans, etc.).   

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 Part 2.  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 Part 2 using
healthcare as a use case.   

The proposed scope for creating this healthcare example for Part 2, a
"reference instantiation" would including a coverage 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.

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

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

Online: www.DigiCert.com <http://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-idassurance/attachments/20110321/0f1509d2/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2032 bytes
Desc: image002.jpg
Url : http://kantarainitiative.org/pipermail/wg-idassurance/attachments/20110321/0f1509d2/attachment-0001.jpe 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2926 bytes
Desc: image003.gif
Url : http://kantarainitiative.org/pipermail/wg-idassurance/attachments/20110321/0f1509d2/attachment-0001.gif 