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] 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" />

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">
    <any namespace="##any" processContents="lax" minOccurs="0"
  <attribute name="Status" type="samlp:StatusCodeType"/>
  <attribute name="SpecificStatus" type="QName"/>
  <attribute name="Message" type="string"/>

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
Office of Info Tech
The Ohio State Univ

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC