Re: SAML Profile StatusCode

[Erik Rissanen <erik@axiomatics.com>]

Hi Steven,

I think this is better than trying to mirror the XACML error.

However, I am a bit worried about the fuzziness between Requester and 
Responder. I am afraid that there will be follow up questions to the TC 
later asking for clarifications for where the line is drawn between 
these two. I'd rather avoid the topic. ;-)

Is it necessary to differentiate between these to at all? I don't 
remember these details of SAML currently. Also, can there be additional 
details about the error? If so, the differentiation may not be needed.

In any case, I am ok with how it is in your proposal if this the usual 
way of doing it in SAML.

Regarding the keywords, the recent post by OASIS of the keyword 
guidelines is in my fresh memory, so I noticed that the proposed text 
mixes the RFC and ISO conventions. SHALL is ISO convention and MAY is 
RFC convention. We should use one consistently. Since the document 
appears to follow the RFC convention as it is now, we should replace 
SHALL with MUST. I can do that if you don't want to change the text 
otherwise.

Best regards,
Erik


On 2014-04-03 01:07, Steven Legg wrote:
> Hi Erik,
>
> On 3/04/2014 1:31 AM, Erik Rissanen wrote:
> > I hadn't noticed the post about the SAML profile. I think it makes 
> > sense to have the SAML status code refer to SAML layer related 
> > errors. Do you have a proposal for how to change the text?
>
> Here is a suggestion for replacing the text following 
> "<samlp:StatusCode> [Required]"
> in Section 4.11.
>
>     The <samlp:StatusCode> element is a component of the 
> <samlp:Status> element in the
>     <samlp:Response>.
>
>     In the response to an <xacml-samlp:XACMLAuthzDecisionQuery>, the 
> value of the
>     <samlp:StatusCode> XML attribute is determined as follows:
>
>     urn:oasis:names:tc:SAML:2.0:status:Success
>
>         This value for the <samlp:StatusCode> XML attribute SHALL be 
> used if and only if
>         at least one XACMLAuthzDecision Assertion (i.e., 
> <saml:Assertion> element) is
>         present. Note that an XACMLAuthzDecision Assertion may 
> indicate XACML errors.
>
>     urn:oasis:names:tc:SAML:2.0:status:Requester
>
>         This value for the <samlp:StatusCode> XML attribute SHOULD be 
> used if an error in
>         the original <xacml-samlp:XACMLAuthzDecisionQuery> prevented 
> evaluation by the
>         XACML PDP.
>
>     urn:oasis:names:tc:SAML:2.0:status:Responder
>
>         This value for the <samlp:StatusCode> XML attribute SHOULD be 
> used if the XACML
>         PDP attempted evaluation of the original 
> <xacml-samlp:XACMLAuthzDecisionQuery>,
>         but was unable to produce a valid XACMLAuthzDecision Assertion.
>
>     Other SAML status codes MAY be used where appropriate when there 
> are no
>     XACMLAuthzDecision Assertions present.
>
> I used "SHOULD" for the "Requestor" and "Responder" statuses because 
> it is sometimes
> fuzzy where the fault lies and to give implementors wriggle room to 
> choose another
> SAML status code where it would make more sense without us having to 
> be prescriptive
> about every single one of them.
>
> The SAML <Status> element is a mandatory child element of the SAML 
> <Response> element
> so one should be provided in the example in Section 4.11. I suggest:
>
>    <samlp:Status>
>      <samlp:StatusCode 
> Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
>    </samlp:Status>
>
> immediately following the <samlp:Response> start-tag.
>
> Regards,
> Steven