[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] Status code proposal
SAML needs an extensible, more fully described status code mechanism. General support for an approach based on, but not directly importing, the SOAP fault approach has been expressed. I suggest a modified design copied from a proposal for hierachical fault codes in SOAP, from Martin Gudgin. I don't know the current likelihood of it (or something like it) being adopted for SOAP 1.3, but it seemed to be favorably received in various forms. I selected the variant I liked the best, but others are possible. This is a hierarchical Status structure to be placed inside Response as a required element. The Status element contains a nested Code tree in which the top level Value attribute is from a small defined set that SAML implementations must be able to create/interpret, while allowing arbitrary detail to be nested inside, for applications prepared to interpret further. I mirrored some of SOAP's top level fault codes, while keeping SAML's Success code, which doesn't exist in SOAP, since faults mean errors, not status. We could rename this to Fault and dump Success if desired. I also eliminated the Error vs Failure distinction, which seems to be intended to "kind of" mean Receiver/Sender, which is better made explicit. Unknown didn't make sense to me either. Please provide clarifications if these original codes should be kept. The proposed schema (unchecked, so somebody should proof it) is as follows, replacing the current string enumeration of StatusCodeType: <simpleType name="StatusCodeEnumType"> <restriction base="QName"> <enumeration value="samlp:Success"/> <enumeration value="samlp:VersionMismatch"/> <enumeration value="samlp:Receiver"/> <enumeration value="samlp:Sender"/> </restriction> </simpleType> <complexType name="StatusDetailType"> <sequence> <any namespace="##any" minOccurs="0" maxOccurs="unbounded" processContents="lax"/> <anyAttribute namespace="##any" processContents="lax"/> </sequence> </complexType> <complexType name="StatusCodeType"> <sequence> <element name="Code" type="samlp:SubStatusCodeType" minOccurs="0"/> </sequence> <attribute name="Value" type="sampl:StatusCodeEnumType" use="required"/> </complexType> <complexType name="SubStatusCodeType"> <sequence> <element name="Code" type="samlp:SubStatusCodeType" minOccurs="0"/> </sequence> <attribute name="Value" type="Qname" use="required"/> </complexType> <complexType name="StatusType"> <sequence> <element name="Code" type="samlp:StatusCodeType"/> <element name="Message" type="string" minOccurs="0"/ maxOccurs="unbounded"/> <element name="Detail" type="samlp:StatusDetailType" minOccurs="0"/> </sequence> </complexType> In Response, replacing the StatusCode attribute, add: <element name="Status" type="samlp:StatusType"/> Some draft text for a new section, perhaps under 2.6.2 Response, describing the structure might be: SAML responses MUST include a Status element describing the outcome of the requested operation in as much detail as the receiver desires to express. 2.6.2.1 Element Status The Status element contains a top-level status code, and optional message and detail information. <Code> [Required] The top-level Code element MUST contain a Value attribute equal to one of the StatusCodeEnumType values. It MAY contain additional Code elements containing Value attributes equal to arbitrary Qnames. A receiver SHOULD provide nested Code elements to fully describe error conditions when possible, but a sender MUST be able to correctly process the Response in a reasonable fashion by examining only the top-level Code element. Four top-level values are defined: Success - The request succeeded. VersionMismatch - The receiver could not process the request because the version was incorrect. Receiver - The request could not be performed due to an error at the receiving end. Sender - The request could not be performed due to an error in the sender or in the request. <Message> [Optional] Any number of Message elements may be included to describe the success or failure condition in human-readable fashion. Multiple languages may be included for I18N purposes. <Detail> [Optional] Arbitrary well-formed XML content may be included to pass application or implementation-specific information to the sender. A receiver MUST NOT require the sender understand the contents of Detail in order to process the response in a reasonable fashion. ----------- Comments welcome. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC