Re: [security-services] Live ISSUEs from Eve

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

Here is the status of my issues, where "discussed" means talked about 
in an actual TC meeting:

ELM-1.  Not discussed; should be put on the issues list and deferred.
ELM-1a. New issue; should be put on the issues list and deferred.
ELM-2.  Discussed positively but never voted; should be implemented.
ELM-3.  Not discussed; should be put on the issues list and deferred.
ELM-4.  Not discussed; should be put on the issues list and deferred.
ELM-5.  Not discussed; should be put on the issues list and deferred.
ELM-6.  Not discussed but a simple/needed fix; should be implemented.
ELM-7.  Discussed positively but never voted; should be implemented.
ELM-8.  Discussed but never concluded; should be done post-freeze.
ELM-9.  Not discussed; should be put on the issues list and deferred.
ELM-10. Not discussed but a purely editorial matter; should be done.
ELM-11. Not discussed but Prateek commented on it; is bindings fixed?
ELM-12. Not discussed; should be put on the issues list and deferred.
ELM-13. Not discussed but Scott commented that it's obvious to fix.

Sorry for the added analysis, but it was difficult to simply say which 
are decided but unimplemented...

	Eve

Eve L. Maler wrote:

>     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