Title: Editor comments on Core-12
In order to clarify (2) as discussed I have made the
following modification to the text, does this clarify
matters?
A
SAML processor will return a certain number of Authentication Assertions in
response to a SAMLQuery
of type AuthenticationQueryType.
The <Subject>
and <AuthenticationCode>
of the returned assertions MUST be identical to the subject (and optional
<AuthenticationCode>)
fields of the SAMLQuery.
There is no implication that all such assertions must be
returned.
A
SAML processor will return a certain number of Authentication Assertions in
response to a SAMLQuery
of type AuthenticationQueryType.
The <Subject>
of the returned assertions MUST be identical to the subject (and optional
<AuthenticationCode>
if present) fields of the SAMLQuery.
There is no implication that all such assertions must be
returned.
Phillip Hallam-Baker FBCS C.Eng.
Principal
Scientist
VeriSign Inc.
781 245 6996
x227
-----Original Message-----
From: Orchard, David
[mailto:]
Sent: Monday, August 06, 2001 6:15
PM
To:
Subject:
Editor comments on Core-12
I have the following comments on the Core-12 and it's
representation of what we agreed at F2F #3. I have not had a chance to
run these issues by the other editors nor do an extensive perusal of the
previous minutes, but I felt it important to report before the tuesday
meeting. This means I don't think that we can close the action item to
produce a consensus draft - because I don't consent :-( I really wanted
to consent as the other editors have done a good job on the schema and other
documentation.
I look at my responsibility as an assigned editor to
faithfully capture what the group agreed to. I believe any divergence
from what was captured should be proposed to the group, rather than changes
made via editorial privilege. Hence my comments are generally about
divergences between what I believe was agreed at F2F #3 and the core-12
document. The changes may be valid from a technical perspective, but I
think they don't follow the process that we agreed to. Or I'm just out
to lunch, which often happens ;-) If it turns out these have all been
discussed by the TC and there are agreed upon decisions, then I clearly
consent to the TC will.
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.
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.
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.
- 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.
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.
Cheers,
Dave Orchard
Phillip Hallam-Baker (E-mail).vcf
