|
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.
|