Comments on XSPA-SAML

I am a healthcare specialist and am the co-chair of the
HITSP security, privacy and Infrastructure committee that has requested OASIS
work on XSPA. I thus understand the overall goal of XSPA. 

 

I have the following combined comments that I (Individual) would
like to submit on the SAML-XSPA-1.0-pr01 profile. Some of these comments may be
found in the soon to be submitted set of comments from HITSP.

 

 

  
  
Document Section and Page Number

  
  
  
Comment Details (including problem, and
  recommended solution)

  
 

 

  
  
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?

  
 

 

  
  
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.

  
 

 

  
  
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.

  
 

 

  
  
2.6

  
  
  
Consider adding a basic statement saying that
  participating information domains have agreed to use XSPA profile and that a
  trust relationship exists

  
 

 

  
  
2.6

  
  
  
Does this profile recommend or specify what
  interactions need to be audited, and how?

  
 

 

  
  
2.6

  
  
  
Please elaborate on what is meant by
  "unique authentication" in this context

  
 

 

  
  
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.

  
 

 

  
  
3.2

  
  
  
what is
  urn:oasis:names:tc:xspa:1.0:environment:locality? This is manditory but not
  explained.

  
 

 

  
  
3.2

  
  
  
There are some attribute identifiers that are
  in this table, but not defined in section 2.12.  Example,
  subject:locality, functional_role.  I would have expected these to be
  described in the previous section.  Also, there are some attributes in
  section 2.12, such as Organization, that are not present in the conformance
  table.

  
 

 

  
  
2.1.1

  
  
  
Interaction between the service user and the
  ACS when requesting an assertion is unclear.  Profile would benefit from
  more details around this interaction.  Or at least a statement
  indicating that no recommendations are made

  
 

 

  
  
2.1.1

  
  
  
"ACS may require additional attributes…" 
  Unclear.  In addition to what?  The service request that is to be
  sent to the SP?

  
 

 

  
  
2.1.1

  
  
  
"Requesting ACS is responsible for the
  enforcement…"  Is this the Service User ACS, or the service
  provider ACS?  If it is the latter, consider moving this statement to
  the next section 2.1.2 where that element is introduced.  The diagram in
  Figure 1, clearly shows that the Decision Enforcment lies between the Service
  Provider and the SP ACS.  This is contradictory if the "requesting
  ACS" is in fact the service user ACS.

  
 

 

  
  
2.12 - 

  
  
  
If both parties agree, can custom attributes
  be added/supported? This level of extension needs to be allowed and stated
  that it is alowed.

  
 

 

  
  
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? 

  
 

 

  
  
2.12 - ACTIONS

  
  
  
This vocabulary seems to be different. I
  don't understand what "Append" is. This is not a action from CRUDE

  
 

 

  
  
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.

  
 

 

  
  
2.12 - Evidence

  
  
  
This is confusing to me.  What element
  is providing this information?  The description seems to imply that an
  authorization decision has already been made, and this attribute is used to
  store the evidence of that decision.  But then, isn't this assertion
  then being passed along to the service provider who then communicates to the
  SP ACS to determine authorization decision? Perhaps this is the
  authentication evidence, and not the authorization evidence?  Clearly,
  I'm missing something.

  
 

 

  
  
2.12 - NPI

  
  
  
Seems arbitrary.

  
 

 

  
  
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? 

  
 

 

  
  
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. 

  
 

 

  
  
2.12 - Organization

  
  
  
Unclear to me how organization is intended to
  be leveraged. If it doesn't impact the access control decision, it may not
  need to be mandatory.

  
 

 

  
  
2.12 - Organization

  
  
  
Is this a placeholder for locality?  If
  not, locality seems to be missing from the 2.12 section.

  
 

 

  
  
2.12 - Purpose of use / Figure 2

  
  
  
Figure may rely too heavily on normative
  reference material.  Doesn't bring home the point it's trying to convey,
  IMHO.

  
 

 

  
  
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?

  
 

 

  
  
2.12 - Second paragraph

  
  
  
Namespace has a typo.  There is a comma
  (,) between the version number 1.0 where it should be a period (.).

  
 

 

  
  
2.12 - Structural Role / Paragraph 1

  
  
  
Missing a period (.) after first sentence.

  
 

 

  
  
2.12 - Structural Role / Paragraph 3

  
  
  
This sentence includes the phrase
  "default structural roles".  Does this imply that a different
  set of roles (other than the default) could be used, or are we required to
  abide by ASTM 1986-98?  If not, the statement regarding the requirement
  of the codeSystem attribute should be made more clear.

  
 

 

  
  
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.

  
 

 

  
  
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.

  
 

 

  
  
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.

  
 

 

 

 

 

John Moehrke

Principal Engineer: Interoperability and Security

GE Healthcare 

 

M +1 920 912 8451



www.gehealthcare.com

 

9900
  Innovation Drive 

Mailstop 2142 

Wauwatosa, WI 
 53226

 

GE imagination at work