Title: Editor comments on Core-12
0. Any time I see a struct with top level elements, I believe
that at least 1 of the top level elements must be required. Otherwise we
used the optional notion. In most cases, all the top level elements must
be required as well.
I
do not understand this comment.
1. Object as described in Core-12 has resources and "actions"
in it, and it should be separate. For example,
AuthorizationDecisionAssertionRequest from the white-board has an Object and
an Action, whereas the Schema has Object which contains Resource and
Action. If some of the editors whish to change the notion of objects to
have actions, then it should be as a proposal. As a TC member, I would
lobby against having object mean resource + action.
You mean Subject, Object Verb? That is what we had in
Core-07
The
issue (if you want toi make one) is strictly aesthetic, whether you consider the
verb to be 'is authorized' or the action. Personally I think the verb 'is
authorized' is implicit in the assertion type.
Raising
the action one level in the structure would not have any semantic impact on
SAML. It would require the current text to be rewritten. The only consequence
that I can think of is that it might affect XACML. I can imagine that you might
want more of a separation there so you can talk about objects and actions
separately. But even that is a stretch.
2. A few of
the structures do not have quite the right cardinalities in them. The
particular structures are:
- Authentication
queries should have 1 authentication code in them, not 0..1
-
Attribute queries should have at least 1 attribute name in them.
According to the actual minutes, the possibility for unbounded # of attributes
is excluded. But I think this was probably a whiteboard scriber error
rather than an explicit TC decision.
On
Authentication queries you are wrong. The client quite likely does not have any
knowledge of the authentication mechanism that was used. Requiring the
client to specify the authentication type in a query would effectively stop
most systems from working.
Again on the attribute queries, I should not be
forced to require the client to specify the attribute.
- See #4 for Attribute Queries.
3. The treatment of wildcard attributes
is a bit confusing. I had understood that we were supporting structured
attributes through the XML Schema wildcard mechanism, but that is not captured
in the minutes nor in the schemas. I think this means I would like to
raise an issue that we do not currently support attributes defined using XML
Schema structures. We do support attributes defined using Name/Value
pairs. Both the previous document submissions had support for this
construct. We do have a wildcard for attribute value, but that only
means we can have structured values and not general
structures.
If
you are going to write an extension schema you might as well define your own
attribute assertion.
4. The treatment of attribute values is a bit confusing. The
minutes indicate that attributes MUST have a name and MUST have 1 or more
values. But the attribute Query refers to attributes and mentions
XPath. I believe this is indicating that there is an Attribute query
String rather than a structure. So I do not believe the attribute query
can refer to an attribute, it must refer to a different "type", such as an
attribute Name type. When/if we do support wildcard attributes, then this
will make even more sense as we'll need a place for the query string like
XPath.
The
string XPATH does not appear in my copy of the
document.
Phill
Phillip Hallam-Baker (E-mail).vcf
