[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] Core 26
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC