[security-services] Live ISSUEs from Eve

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

	ELM-1. Common attributes on standalone SAML elements

This item should probably be low priority and it's relatively invasive 
to the spec, but it may appeal to implementors.  If it does, we should 
consider it seriously.

We define the MajorVersion, MinorVersion, and IssueInstant attributes 
three times: once on AssertionType, once on RequestAbstractType, and 
once on ResponseAbstractType.  These similarities are based in the 
fact that all three are "root" SAML constructs that can be used 
standalone and are "issued" by someone.  If there will be any 
processing associated with these attributes (and I think there will 
be, otherwise we wouldn't have the attributes nor Section 4), it would 
be ideal to factor this out into a type in order to avoid redundancy 
in the schema and make it easier to bind application-level handling.

I propose an "ur-type" called RootElementType that is defined as follows:

<complexType name="RootElementType"
   <attribute name="MajorVersion" type="integer" use="required"/>
   <attribute name="MinorVersion" type="integer" use="required"/>
   <attribute name="IssueInstant" type="dateTime" use="required"/>
</complexType>

and that the three relevant types inherit from this type in the 
following fashion (and the prose around those things changes 
correspondingly):

<complexType name="AssertionType"> <!-- for example -->
   <complexContent>
     <restriction base="RootElementType">
       <!-- the other stuff they currently define goes here -->
     </restriction>
</complexType>

The new complex type would have to be defined in prose in the spec.  I 
propose the following definition:

"1.2.3 Complex Type RootElement Type

The SAML assertion, request, and response data structures share some 
identifying features because they MAY all serve as the root of the 
SAML-based portion of an electronic communication.  The complex type 
RootElementType defines these shared features. ..."

---------------------------------
Auxiliary issue ELM-1a. Genericize ID attribute names

These three elements have ID attributes, but they all have different 
names.  Are we interested in genericizing this attribute name to "ID" 
and adding it to RootElementType?  It's quite common to use the 
generic name "ID" for identifiers in XML.

---------------------------------
ELM-2. Remove AssertionSpecifier

The <AssertionSpecifier> element appears in instances but we don't get 
anything good out of its presence; it's a nonterminal masquerading as 
a terminal.  Its contents consist of a single choice among AssertionID 
and Assertion; 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.

I propose to redefine <AdviceType> as follows:

<complexType name="AdviceType">
   <choice minOccurs="0" maxOccurs="unbounded">
     <element ref="saml:Assertion"/>
     <element ref="saml:AssertionIDReference"/>
     <!-- other advice stuff; see also issue ELM-4 -->
   </choice>
</complexType>

---------------------------------
ELM-3. Change Evidence

The <Evidence> element is currently repeatable, and contains only a 
single assertion or assertion ID reference.  It would make more sense 
to allow a series of assertion information inside a single <Evidence> 
element as follows:

<complexType name="AuthorizationDecisionStatementType">
   <complexContent>
     <extension base="saml:SubjectStatementAbstractType">
       <sequence>
         <element ref="saml:Actions"/> <!-- since changed, though -->
         <element ref="saml:Evidence" minOccurs="0"/>
       </sequence>
       <!-- etc. -->
     </extension>
   </complexContent>
</complexType>

<element name="Evidence" type="EvidenceType"/>
<complexType name="EvidenceType">
   <complexContent>
     <choice maxOccurs="unbounded">
       <element ref="saml:Assertion"/>
       <element ref="saml:AssertionIDReference"/>
     </choice>
   </complexContent>
</complexType>

This has the nice side effect of getting ride of 
AssertionSpecifierType, which (if ELM-2 is accepted) no longer has a 
corresponding element.

---------------------------------
ELM-4. Remove <AdviceElement>

We offer two ways to provide arbitrary advice: <AdviceElement> and the 
##any wildcard.  I'm not sure why anyone would go to the bother of 
defining a custom type on top of AdviceElementType when they can just 
use whatever elements they want.  I think we should remove 
<AdviceElement> and just stick with the wildcard.  Alternatively, I 
think we should get rid of the wildcard and force people to inherit 
from AdviceElementType if we think that's so important.

---------------------------------
ELM-5. Reorder the contents of <Conditions>

The content model for <Conditions> should be rationalized 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>

---------------------------------
ELM-6. Refer to URI references

We keep talking about "URIs" in most places throughout, but we 
actually mean URI references (with the option of putting # fragment 
identifiers on the end).  We should say "URI reference" throughout.

---------------------------------
ELM-7. Talk about SAML authorities/responders 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.  We should 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.

---------------------------------
ELM-8. WSDL

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

---------------------------------
ELM-9. Empty strings, IDs/ID references, and URIs

After reflection, I think we should enforce non-emptiness for strings, 
IDs, and ID references.  The rationale is that it performs a useful, 
though not sufficient, test for correctness and we should try to get 
the most we can out of "free" validation.

The easiest way to do this is probably to define a saml:StringType 
type that's based on xsd:string:

<!-- I *think* this is the right syntax! -->
<simpleType name="StringType">
   <restriction base="xsd:string">
     <minLength>1</minLength>
   </restriction>
</simpleType>

and then use it for all the xsd:string cases, as well as basing 
saml:IDType and saml:IDReferenceType on it.

As for empty URI references, I think we need to include something in 
the prose in each case about the meaning of empty ones.  In the case 
of all the "namespace"-type usages of URI references, we may even want 
to force non-empty content by a means such as the above one.  But for 
the Resource attribute, I think we merely need to say what the 
semantics are in the case that the value is empty.  The two obvious 
choices are (a) the current document (RFC 2396 meaning) and (b) 
results are undefined.  If we agree on the latter, we might as well 
force that to be non-empty, too.

---------------------------------
ELM-10. Handling of acknowledgments

See MS-2-02.

---------------------------------
ELM-11. Test cases for artifact handling

According to Test Case 1-2, 1-3, 1-6, 1-10 in the conformance spec 11, 
a SAML Request is sent over SOAP protocol binding to a responder. The 
responder should be able to return an assertion artifact in the 
Response. The requester then request the assertion using the artifact.

The key here is an artifact is requested for ANY type of assertion AND 
  over SOAP protocol binding. I don't see these requirement anywhere 
else, not even in Table 1: Protocol Bindings and Profiles for SAML 
Assertions. Are they intended or should be removed?

---------------------------------
ELM-12. Protocol for artifact- and ID-based queries

See:


http://lists.oasis-open.org/archives/security-services/200202/msg00204.html

Has this been decided/fixed?

---------------------------------
ELM-13. InResponseTo when the request is missing/malformed

See:


http://lists.oasis-open.org/archives/security-services/200203/msg00001.html

Has this been decided/fixed?

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



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