[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" /> </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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC