Subject: Re: SAML Profile StatusCode
Hi Steven,I'm in a hurry now, so I will review the technical content another moment, but regarding the keywords, I was thinking of that it says:
"3.1 Introduction to KeywordsThe term keywords for OASIS specifications or standards means terms specified either by [RFC 2119] or the [ISO/IEC Directives]. Every OASIS specification or standard will choose (and use) one or the other. The two keyword sets are never mixed in a specification or standard."
I did not see "SHALL" listed in the RFC section of the OASIS guidelines, so I thought it was not allowed. However, as you say, the RFC document itself has SHALL as an option, so I guess it is ok for us to use it.
To me that's great. Less work to updated the other profiles, so I won't worry about this then. :-)
Best regards, Erik On 2014-04-04 00:55, Steven Legg wrote:
Hi Erik, On 3/04/2014 11:52 PM, Erik Rissanen wrote: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. ;-)I was more worried about seeming to be too strict about, for example, requiringRequestor when VersionMismatch would be more appropriate.Is it necessary to differentiate between these to at all?No. The key point is that the SAML StatusCode is "Success" if there is at least one XACMLAuthzDecision Assertion and something other than "Success" if there is noXACMLAuthzDecision Assertion. The replacement text could be simplified: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 MUST be "urn:oasis:names:tc:SAML:2.0:status:Success" if and only if at least one XACMLAuthzDecision Assertion (i.e., <saml:Assertion> element) is present. Note that an XACMLAuthzDecision Assertion may indicateXACML errors. It would be redundant, but perhaps helpful to add:Where there is no XACMLAuthzDecision Assertion, some other SAML status code ischosen as befits the reason for the absence.> I don't remember these details of SAML currently. Also, can there be additional details about the error?The Status can include a StatusMessage and/or StatusDetail. > 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.I'm not familiar with other uses of SAML, but I have seen protocols that map application errors into HTTP errors. It's a bad idea however common the practicemight be.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.On re-reading the guidelines (https://www.oasis-open.org/policies-guidelines/keyword-guidelines), I find nothing that prohibits the use of the RFC 2119 "SHALL" when following the RFC 2119conventions in an OASIS specification.That said, "SHALL" and "MUST" are interchangeable, so I don't have a problem with you changing the "SHALL" to a "MUST". However, if you want to be consistent, there are other uses of "SHALL" in the SAML profile and I noticed in passing that the RBAC profilealso uses "SHALL". I didn't check any of the other profiles. Regards, StevenBest 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:SuccessThis 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:RequesterThis value for the <samlp:StatusCode> XML attribute SHOULD be used if an error in the original <xacml-samlp:XACMLAuthzDecisionQuery> prevented evaluation by theXACML PDP. urn:oasis:names:tc:SAML:2.0:status:ResponderThis 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 noXACMLAuthzDecision 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 prescriptiveabout every single one of them.The SAML <Status> element is a mandatory child element of the SAML <Response> elementso 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