OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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