Title: Editor comments on Core-12
Sorry,
2nd try:
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>
element of the SAMLQuery.
If the <AuthenticationCode>
field is present in the SAMLQuery
the <AuthenticationCode>
field in the response MUST match. 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: Hallam-Baker, Phillip
[mailto:]
Sent: Tuesday, August 07, 2001 1:10
PM
To: 'Orchard, David';
Subject: RE: 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
