RE: [security-services] Status code proposal

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

> I thought the other approach -- an array of elements, the 
> first one being distinguished as it must come from a 
> specified set -- was getting better consensus.  It avoids 
> subtle "what is more detail" semantics, and lets you provide 
> "alternate views on what happened" semantics. 
> (Disclaimer:  it was also my idea. :)

I asked for an update on the list on which was getting better feedback,
and didn't get much of a response (none, actually). About all I saw was
Henrik's note that I replied to. So, I picked the one I liked. :-)

My reasoning is that it feels weird to me to have them all at one level
and use order/positioning to identify the "main" status, but that's just
a personal feeling. I don't pretend to be an expert on what works best
in XML.

> On a more major issue, is the intent that SAML status codes 
> be able to carry transport errors?  For example, if I'm doing 
> SAML over soap, and the soap library gets a SOAP fault, can 
> the local SAML library wrap that up in a SAML message to 
> present to the local application?  *Should it?*

Right now, the sense seems to be not. Simon G. was pretty explicit in
his notes and the SOAP binding that SOAP errors are SOAP faults, and
only SAML-processor problems would be SAML status codes, and I'm
proceeding from that assumption.

-- Scott