[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] Approved changes/cleanup for Status/StatusCode/etc.
I took an AI to resend the changes to status code text and schema based on the approved change from the last meeting. This should clean up the text for the final document as well, and incorporates text Eve and I discussed to make the use of QNames as precise as possible. The only substantive changes are the conversion to Requester/Responder terminology in the text (agreed to a while ago), and the removal of the enumeration of top level codes as approved during the last meeting, which eliminates several pieces of the schema. The rest is for editorial correctness. I believe all references to status codes in the core document are correctly phrased with these changes. Other documents (bindings?) might need to be double checked. Changes: In protocol-28.xsd, change the definition of StatusCodeType to the following: <complexType name="StatusCodeType"> <sequence> <element ref="samlp:StatusCode" minOccurs="0"/> </sequence> <attribute name="Value" type="QName" use="required"/> </complexType> Delete the StatusCodeEnumType and SubStatusCodeType types, and the SubStatusCode element. The text for section 3.4.3.1 should be changed to the following: ----begin new text for section 3.4.3.1---- The <StatusCode> element specifies one or more nested codes representing the status of the corresponding request. The top-most code value MUST be one of the values defined below. Subsequent nested code values, if present, may provide more specific information concerning a particular error. Value [Required] The status code value as defined below. <StatusCode> [Optional] An optional subordinate status code that provides more specific information on an error condition. The following top-level StatusCode Value QNames are defined. The responder MAY NOT include a code not listed below except by nesting it below one of the listed values. Success The request succeeded. VersionMismatch The responder could not process the request because the version was incorrect. Responder The request could not be performed due to an error at the responding end. Requester The request could not be performed due to an error in the request. 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. RequestVersionTooHigh The SAML protocol version specified in the request is a major upgrade from the highest protocol version supported by the responder. RequestVersionTooLow The responder cannot respond to the particular request using the SAML protocol version specified in the request because it is too low. RequestVersionDeprecated The responder does not respond to any requests with the SAML protocol version specified in the request. TooManyResponses The response would contain more elements than the responder will return. ResourceNotRecognized The request included a URI reference to a resource that the responder does not understand or recognize. 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, but MAY NOT define additional codes in either the SAML assertion or protocol namespaces. The QNames defined as status codes SHOULD only be used in the StatusCode element's Value attribute and have the above semantics only in that context. The following schema fragment defines the <StatusCode> element and its StatusCodeType complex type: <schema fragment changed as mentioned earlier> ----end new text for section 3.4.3.1---- Section 3.4.3.2 should be deleted. Section 3.3.4, change line 1314 to: SHOULD respond with a top-level StatusCode value of Responder and a second-level code value of ResourceNotRecognized. Section 4.3, change line 1586 to: An error response resulting from 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: -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC