RE: [security-services] Core 26

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

> 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