|
Documents
Under Review:
|
|
|
|
OASIS
XSPA XACML
|
Cross-Enterprise Security and Privacy
Authorization (XSPA) Profile of XACML v2.0 for Healthcare
|
|
|
OASIS
XSPA SAML
|
Cross-Enterprise Security and Privacy
Authorization (XSPA) Profile of Security Assertion Markup Language (SAML) for
Healthcare
|
|
|
|
|
|
|
Commenter
Name and Organization:
|
|
|
|
|
|
|
Document
Name or Number
|
Document
Section and Page Number
|
Comment
Details (including problem, and recommended solution)
|
|
OASIS XSPA SAML
|
2.12
|
Need to have direction on how a
functional role can be specified . It is recognized that functional roles are
difficult to standardize, but it is certainly possible within a specified
domain that a functional role vocabulary could be identified. Thus that
specific domain would need to have guidance on how to convey the functional
role.
|
|
OASIS XSPA SAML
|
2.12 - ACTIONS
|
It is not clear why the assertion should
contain information about the underlying service-request. There should be
separation of claims about the identity requesting access to a resource, and
claims about the action and resource. This might be simply clarity on where
this XSPA-SAML applies vs when a SAML-Identity-Assertion applies. Given the
diagram in Figure 1, I am not clear on where the XSPA-SAML profile applies.
Which transaction?
|
|
OASIS XSPA SAML
|
2.12 - ACTIONS
|
This vocabulary seems to be different. I
don't understand what "Append" is. This is not a action from CRUDE
|
|
OASIS XSPA SAML
|
2.12 - OBJECTS
|
There needs to be clear guidance on the
precidence between SNOMED-CT and HL7 RBAC Permissions. When they both have an
equivilant vocabulary term, which one should be used?
|
|
OASIS XSPA SAML
|
2.12 - OBJECTS
|
There should be guidance that indicates
how to utalize a private vocabulary. This private vocabulary should be
allowed when the formal vocabulary is not sufficient to describe the object.
|
|
OASIS XSPA SAML
|
2.12-OBJECTS
|
One possibility for an object is to
include the object's unique ID. For example if the object is a CDA document, then
the object can be described by the document unique ID.
|
|
OASIS XSPA SAML
|
2.12-Purposofuse
|
The list of purposes don't have unique
IDs. Isn't there a purpose of use table in ASTM or HL7? If this area is one
that is still under development then we should state that.
|
|
OASIS XSPA SAML
|
2.12 - Resource
|
It is unclea what "Resource"
is referring to other than the previously described "object". Which
one is to be used? Object or resource? If they are diferent, then how are
they different?
|
|
OASIS XSPA SAML
|
2.12 - evidence
|
This is not described well enough for me
to understand what it is. If this is a concept under-development then we
should not include it here, at least not normatively.
|
|
OASIS XSPA SAML
|
2.12 general
|
This section seems to have
sub-organization but it is not clear because the section-numbering is turned
off. Please arrange this section so that it is easer to understand the
grouping of these sub-concepts.
|
|
OASIS XSPA SAML
|
3.2
|
Some identifiers are identical. (HL7
Permission Catalog Permission, and HL7 Permission Catalog Resource Actions)
and (SNOMED CT
Permissions, SNOMED CT
Resource Actions, and SNOMED CT
Objects). These are two different concepts, they should not be in the same
vocabulary set.
|
|
OASIS XSPA SAML
|
3.2
|
what is
urn:oasis:names:tc:xspa:1.0:environment:locality? This is manditory but not
explained.
|
|
OASIS XSPA SAML
|
2.1
|
It is not clear why the assertion should
contain information about the underlying service-request. There should be
separation of claims about the identity requesting access to a resource, and
claims about the action and resource. This might be simply clarity on where
this XSPA-SAML applies vs when a SAML-Identity-Assertion applies. Given the
diagram in Figure 1, I am not clear on where the XSPA-SAML profile applies.
Which transaction?
|
|
OASIS XSPA SAML
|
2.2
|
Again, this seems indistinguishable from
a C19 like claim about the identity. Is this XSPA-SAML profile a further constraint
on C19? Or is it describing some other transaction? This seems very much like
further constraints on C19. I think this is the right thing to do with this
specification.
|
|
OASIS XSPA SAML
|
2.3
|
In HITSP terms this is T17, right?
|
|
OASIS XSPA SAML
|
2.4
|
In HITSP terms this is T17, right?
|
|
OASIS XSPA XACML
|
all
|
In using the terms for normative
statements as described in section 1.1, I don't find any new normative
statements in this specification. The statements I find with MUST listed are
just restatements of the underlying standard requirements. I therefore can
not determine the purpose of this specification.
|
From: Moehrke, John
(GE Healthcare)
Sent: Friday, February 27, 2009
12:29 PM
To: xspa@lists.oasis-open.org
Subject: My Comments on XSPA-SAML
and XSPA-XACML
Here are my comments on the XSPA-SAML and XSPA-XACML public
comment drafts. I will submit these formally to the appropriate committee
list-serve, but am also providing them to the XSPA committee for your
information. These comments were used by the HITSP-SPI committee as input to
the comments that OASIS will receive from HITSP. Some comments received very
useful clarification in the HITSP discussion, so I encourage the use of the
HITSP version when they become available.
John Moehrke
Principal Engineer: Interoperability and Security
GE Healthcare
M +1 920 912 8451
John.Moehrke@med.ge.com
www.gehealthcare.com
9900
Innovation Drive
Mailstop 2142
Wauwatosa, WI
53226