[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [security-services] Status code clarifications/cleanup
At 01:51 PM 2/18/02 -0500, Scott Cantor wrote: >1) Removal of StatusCodeEnumType > >I've realized that if we define the base set of four status codes in the >schema, as an enumeration of QNames, the schema then mandates that the >namespace prefix of "samlp" appear inside the status code value. A >restriction derivation of QName seems to be lexical instead of logical, >essentially. I think this is weird, but it seems to be a consequence of >the poor handling of QNames in XML because they were tacked on >afterward. > >It should be legal for any namespace prefix to be used as long as it >maps to the correct namespace URI (the SAML protocol namespace in this >case), so my suggestion is to remove the eumeration from the schema and >then collapse the StatusCode schema definition to: > ><complexType name="StatusCodeType"> > <sequence> > <element ref="samlp:StatusCode" minOccurs="0"/> > </sequence> > <attribute name="Value" type="QName" use="required"/> ></complexType> > >StatusCodeEnumType, SubStatusCodeType, and the SubStatusCode element can >then be deleted along with corresponding cleanup of the element >descriptions in the document. In 3.4.3.1 where it defines the codes, it >could say something like: > >"The following top-level status code values are defined:" > >Then underneath those: > >"The following second-level status codes are referenced at various >places in the specification. Additional subcodes may be defined in >future versions of the SAML specification." > >The disadvantage to this is that it moves the validation/checking of the >four mandatory Status Codes out of the schema and into the SAML >implementation, but personally I think lexically validating the samlp >prefix in the QNames is even worse. > >If there's a better way to create an enumeration of QNames that doesn't >suffer from this drawback, I guess that would be the alternative to >this, but I haven't found one. The real problem is that QNames in attribute values are a totally unsanctioned use of the XML namespace mechanism (as far as the XML Namespaces spec is concerned, that is). There was just another huge thread on the problems associated with QNames in attribute values on XML-Dev... It's been done so often, though, that I'm not really willing to fight to get rid of it. But we should know the costs (see below). >--------------- > >2) Change Sender/Receiver to Requester/Responder > >This is a suggestion of Simon Godik's that got lost somewhere, but it >was a good one, IMHO. The latter terminology is more consistent with the >usage and the other documents, so I think the four top-level codes >should be Success, VersionMismatch, Requester, and Responder. I have made this request too, though not on the codes -- just on the prose in the spec. I support this one. >--------------- > >3) Clarifying section on namespace of status codes in the document > >I suggest adding a section after the current section 1.2.1 (Time Values) >as follows: > >1.2.2 Status Code Values > >All status code values defined in this document are QNames associated >with the SAML protocol namespace [SAMLP] and MUST be prefixed >approprately when they appear in SAML messages. SAML extensions and >applications are free to define more specific status codes in other >namespaces. If we're really going to do this, I think we also need to document who/what governs the uniqueness of this field. Conceptually, the original scope "partitions" containing sets of unique names were: elements, global attributes, and local attributes per element. If we ever add another attribute to SAML that contains qualified names, is it possible that it will share some values with the status code values (thus being in a different scope), or will it be impossible to re-use values for that new attribute (suggesting that it's in the same scope)? (The other weird thing about QNames in attribute values bothers me more: They're a function of a particular application (e.g., SAML) and not a function of basic XML syntax and processing. This means that such attribute values are left out in the cold when you perform processing on XML documents qua XML, for example, changing prefixes throughout.) >--------------- > >4) Additional cleanup of document > >The following changes should clean up the specification of what codes >are defined and how they're used, especially subcodes. I use the changed >terminology from Simon from suggestion (2) above. > >Section 3.3.4, change line 1116 to: > >SHOULD respond with a top-level StatusCode value of Responder and a >second-level value of ResourceNotRecognized. > >Section 4.3, change line 1374 to: > >Incompatible protocol versions MUST result in reporting a top-level >StatusCode value of VersionMismatch, and MAY result in reporting one of >the following second-level values: > >If I missed any spots, similar text can be used as above. Eve -- 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