> I'm probably not directly in the position to demonstrate this
> for SAML, though afaik none of the existing web access control
> products, (that do work), have anything near such complex status
> structures, which is some sort of a demonstration I guess.
SAML use cases aren't confined to that problem space, however, and
adding useful functionality on top of just saying "success/fail" to a
particular existing call has to go someplace. Also, note the schema
itself is extensible to new assertion types and new requests/responses
(which may bother you as well, I don't know).
The structure itself is just copied from the coming drafts of SOAP, by
the way (in case you missed any of the origins), although even SOAP 1.1
has a dot notation for nested status codes.
But admittedly another way to approach this could have been to define a
base type that could be extended outside of this schema by the
application's extension schema. An enum wouldn't do, but it wouldn't
take much more.
> I'm also reminded of problems that arose with GSS-API
> minor_status return codes - programmers wrote code that
> branched on those values (though the spec said not to!)
> resulting in breaking portability for their applications
> (since GSS-API providers were free to put whatever
> they wanted into the minor_status in lots of ways). I'm of the
> (admittedly unprovable) opinion that this was inevitable once a
> non-opaque minor_status return parameter was defined.
I guess I can't argue that point either way. I can promise not to if it
helps. ;-) Certainly some applications may dictate a stricter processing
model because they need one, which is the whole reason for defining it.
> Exactly. My preference is to omit all optional complexity.
> (Sophistry, I know:-)
Well, optional is in the eye of the beholder/application. If all an
implementation cares about is what's not optional, they don't have to do
more work. I doubt they would be interop'ing with implementations that
do care anyway, since the application models layered on top of SAML are
probably different.
-- Scott
