[security-services] Status Code proposal

[Scott Cantor <cantor.2@osu.edu>]

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