[security-services] Sun comments on core-25

["Eve L. Maler" <eve.maler@sun.com>]

Sun comments on core-25

The high-priority list below reflects our hopes for resolution before
the last-call draft gets published, though we know that the current
schedule makes this difficult.  Some of the low-priority items can
wait till SAML 1.x, but others would be best (and in some cases
easily) taken care of just after SAML 1.0 last call.  We may have
more comments later.

(Note that many of these comments were made at core-19 and again at
core-21.  These do not appear to be on the issues list.)

=================================
High-priority:
---------------------------------
H1. Resource and Decision optionality

On AuthorizationDecisionStatement (Section 2.4.4), How can the
Resource attribute value be optional?  If it can be absent, how should
the resource be interpreted?   We would prefer to make it required.

Also, how can the Decision be optional?  This doesn't seem to make
sense, particularly since Indetermine is a possible value.

---------------------------------
H2. Queries that return multiple assertions and statements

Some of the language in the sections describing the queries (Section
3.3) talks about responses returning *an* assertion, *a* statement.
We need to clarify the circumstances under which multiple ones can be
returned as a part of the definition of the protocol.

As a specific case, what does it mean for multiple
AuthenticationAssertions to be returned from an AuthenticationQuery?
Intuitively, it would seem that only one can be returned after a user
logged in.  If it's wrong to return multiple ones, we would need to
use some MUST NOTs in prose to disallow them; syntactic solutions
would be difficult or impossible to achieve.

---------------------------------
H3. Comparison functions of Subject and ConfirmationMethod

In Section 3.3.3, it is said that the Subject element in the returned
assertions MUST be identical to the Subject element of the
AuthenticationQuery. Is it true for AttributeQuery and
AuthorizationQuery as well?

Also, is our recent decision about comparison functions enough to
cover both the Subject matching and ConfirmationMethod matching that
are mentioned in this section?

---------------------------------
H4. SubjectConfirmation potentially obviating authN assertions

The following comment is quoted nearly verbatim from a colleague:

Section 2.4.2.3 defines SubjectConfirmation as being used to supply
data that allows the subject to be authenticated. What exactly does
this mean?

It would seem strange to use this field with authentication assertions
to duplicate the authentication that the assertion is purportedly
representing. I guess it can be used to authenticate the identity of
the presenter of the assertion, when it is other than the subject, but
as defined it doesn't allow for that.

In the case of attribute and authorization decision assertions, it
would seem that it could be used to authenticate the subject of the
assertion, but in that case, I would guess it to be used in lieu of an
authentication assertion.

Jumping ahead to Section 6, I now see that it is really about key
distribution. How to get the key (or something like a key) to the
relying party, such that it is available there for the purpose of
proving that the holder of the assertion is the subject?

On this count, I would think there should be other confirmation
mechanisms that effectively combine the confirmation mechanism in
Section 7.1.6 (the hash of the password) with assertion data, such
that a password hash is not reusable (because then knowing it is as
good as knowing the password).

---------------------------------
H5. ConfirmationMethod vs. AuthenticationMethod

On the surface, there is little explanation of how these two
constructs differ.  There needs to be a lot more prose for both,
reflecting TC discussions to date.

---------------------------------
H6. AssertionID and IDType need refactoring

The AssertionID element (Section 2.3.2) has a confusing name, given
that there is an AssertionID attribute that *assigns* IDs, and given
that the purpose of this element is to *reference* assertions that
have such assignments. AssertionReference or AssertionIDReference
would be a better name.

Also, the attributes that are of IDType but are meant to be ID
*references* (the AssertionIDRef element and the InResponseTo
attribute) need to be given a different type, because the semantics of
IDType (Section 2.2.1) are clearly meant to apply to unique ID
assignments, not (possibly multiple) references to such IDs.  We need
a type called IDReferenceType.

<simpleType name="IDReferenceType">
   <restriction base="string"/>
</simpleType>

<element name="AssertionIDRef" type="saml:IDReferenceType"/>

<complexType name="ResponseAbstractType">
   ...
   <attribute name="InResponseTo" type="saml:IDReferenceType" .../>
   ...
</complexType>


=================================
Low-priority:
---------------------------------
L1. Common attributes on standalone SAML elements

MajorVersion and MinorVersion attributes are defined over and over
again, and now we will also have IssueInstant defined multiple times.
There are two possible solutions to this redundancy.

1. Define an "ur-type" (called, say, RootElementType) that defines the
    attributes that must appear on SAML elements that are allowed to be
    "roots" as far as SAML is concerned and then have
    RequestAbstractType, ResponseAbstractType, and
    AssertionAbstractType
    inherit from it.

2. Define an attribute group in assertion-19 that can be referenced in
    all three places.

#1 seems the better solution, if we can agree on the semantics of
RootElementType.

---------------------------------
L2. Facets for version integers

Again regarding MajorVersion and MinorVersion, I thought we were going
to use facets to ensure that the integer is positive.  We would want
to make a VersionNumberType simple type for this.  But this is not
critical to do.

---------------------------------
L3. Make NameIdentifier non-empty

NameIdentifier and its type (Section 2.4.2.2) add up to an empty
element.  Given our distaste for attributes in general, it seems
better for NameIdentifier to use element content for its "main"
purpose (e.g., what's currently in its Name attribute).

---------------------------------
L4. Remove AssertionSpecifier

I think we really don't need the <AssertionSpecifier> element (Section
2.3.1).  It's basically functioning as a concrete schema model group
and doesn't add any juicy semantics -- we will have
<saml:AssertionSpecifier> in instances but we don't get anything
good out of its presence.  Since its contents consist of a single
choice among AssertionID and Assertion, and since AdviceType
references this element in the context of an unbounded (repeatable)
<choice> group (which could simply have listed AssertionID and
Assertion separately), the parent element seems to serve no particular
function.

(Keeping the AssertionSpecifier type, which is used in the definition
of Evidence, isn't such a bad idea, but it doesn't add that much
either.)

---------------------------------
L5. Reorder the contents of the Conditions element

The content model for Conditions (Section 2.3.3.1) should be
rationalized a bit to put the SAML-native stuff first and pick an
order.  It's more complicated to allow a mixture than to require any
native information to go first and allow extension stuff to trail
behind.  Also, if you allow a mixture, often it's because there are
semantics in the order; here that's not the case, so nailing down an
order is good and doesn't cost implementors anything.  Here's how the
schema would look with this change:

<complexType name="ConditionsType">
   <sequence>
     <element ref="saml:AudienceRestrictionCondition"
       minOccurs="0" maxOccurs="unbounded"/>
     <element ref="saml:TargetRestrictionCondition"
       minOccurs="0" maxOccurs="unbounded"/>
     <element ref="saml:Condition"
       minOccurs="0" maxOccurs="unbounded"/>
   </sequence>
   ...
</complexType>

---------------------------------
L5. URI references

We keep talking about "URIs" in most places throughout, but do we
really mean to exclude URI references (with # fragment identifiers on
the end)?  I don't think so.  We should say "URI reference"
throughout.  I've contributed some definitions to the Glossary that I
hope will help our readers understand the difference.

I'd like to see this one taken up before we go final with 1.0, but it
shouldn't stop Last Call.

---------------------------------
L6. Talk about SAML authorities and requesters

There are several terms bandied about in this spec that I'm concerned
are underdefined or inappropriately used: [SAML] application, [SAML]
client, [SAML] service.  And there are terms that I'm surprised are
*not* used: authority, requester, responder.  I'd like to suggest that
we use "requester" instead of "client", because a requester could be a
service itself; and that we use "[SAML] authority" instead of "[SAML]
service" because we've carefully defined the former term.

---------------------------------
L7. Clarify use of xsi:type for native constructs

AuthorizationDecisionQuery in an instance doc can be either of the
following:

<AuthorizationDecisionQuery>...
<SubjectQuery xsi:type="samlp:AuthorizationDecisionQueryType">...

Some implementors may think that the second method is preferable;
while it should be supported by consumers of SAML constructs, it
shouldn't be the preferred way used by producers of SAML constructs.
Since XML Schema is so new, do we need to say anything about this
situation?

---------------------------------
L8. WSDL

We should publish Irving's WSDL for SAML 1.0, even if in non-normative
form.


=================================
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com