RE: [security-services] Status Code proposal

[Simon Godik <sgodik@crosslogix.com>]

Title: RE: [security-services] Status Code proposal

Saml error discussion follow-up.

From my point of view it is better to define saml error structure that is independent of any bound protocol. Any error condition that is raised before

control is passed to saml assertion processor should be reported in the context
of the bound protocol. Any error condition that is raised by the saml processor
should be reported withing saml error framework (possibly as a child of saml:Response element).
If we take soap on top of http binding as an example, http authentication failure,
incorrect content-length are examples of errors from the lower protocol layer
(http). The second type of errors should be reported by the soap layer: request
method other than post, incorrect soap namespace, incorrect saml namespace,
misunderstood soap headers - all of these should be returned within
soap:Fault element.
Then we get to saml errors - those could be broken down in syntax errors and semantic errors.
Syntax errors: assertion is not conforming to schema. Semantic errors: signature
does not validate, assertion attachment can not be verified, subject can not be
confirmed, etc.

Simon Godik
Crosslogix

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu]
Sent: Monday, October 29, 2001 10:22 AM
To: security-services@lists.oasis-open.org
Subject: [security-services] Status Code proposal

I offered to propose a revamp/expansion of the existing StatusCodeType in
protocol-19 to try and get a discussion started that hopefully can be
finished by others at the FtF.

Reviewing the existing schema:

<simpleType name="StatusCodeType">
  <restriction base="string">
    <enumeration value="Success" />
    <enumeration value="Failure" />
    <enumeration value="Error" />
    <enumeration value="Unknown" />
  </restriction>
</simpleType>

Core-19, in the section on versioning already defines new error codes that
aren't listed here, so presumably we can assume there's already a need to
extend this. Applications are likely to want to define their own codes in
addition to those SAML defines.

I propose defining several "levels" of detail for use by both SAML
components and applications built on top of them. This is more or less
patterned after SOAP. First the proposal:

<element name="StatusInfo" type="samlp:StatusInfoType"/>
<complexType name="StatusInfoType">
  <sequence>
    <any namespace="##any" processContents="lax" minOccurs="0"
        maxOccurs="unbounded"/>
  </sequence>
  <attribute name="Status" type="samlp:StatusCodeType"/>
  <attribute name="SpecificStatus" type="QName"/>
  <attribute name="Message" type="string"/>
</complexType>

This builds on the current attribute and changes it to a StatusInfo element
that contains the existing high-level status, but adds three additional
"channels". The SpecificStatus is a QName, so it's namespace qualified,
providing the ability for SAML to define its own specific codes (like the
ones in core-19) and for layered applications to define their own codes
without colliding.

The Message seems like a good thing to have, for basic "readable" error
messages (might need some additional stuff for proper I18N)

Finally, the StatusInfo element can contain aritrary XML for passing
structured error information if both sides understand what to expect, based
on the SpecificStatus, probably.

I think this is pretty clean, but error handling is a can of worms, so I'm
sure opinions differ. Have at it.

-------------------
Scott Cantor
cantor.2@osu.edu
Office of Info Tech
The Ohio State Univ

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>