[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] Live ISSUEs from Eve
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC