RE: [security-services] A "final" proposal on status codes

[Simon Godik <sgodik@crosslogix.com>]

Title: RE: [security-services] A "final" proposal on status codes

Scott,

This is good status code proposal.

I think it is better to use samlp:Requestor and samlp:Responder in samlp:StatusCodeEnumType definition rather
than samlp:Sender and samlp:Receiver. Also, we can also refer to 'saml requestor' and 'saml responder' in the descriptive

text.

<simpleType name="StatusCodeEnumType">
    <restriction base="QName">
        <enumeration value="samlp:Success"/>
        <enumeration value="samlp:VersionMismatch"/>
        <enumeration value="samlp:Requestor"/> <------ suggested replacement
        <enumeration value="samlp:Responder"/> <------ suggested replacement
    </restriction>
</simpleType>

>2.6.2.1 Element Status
>....[deleted]
><Code> [Required]
>The top-level Code element MUST contain a Value element equal to one of
>the StatusCodeEnumType values. It MAY contain additional nested Code
>elements containing Value elements equal to arbitrary QNames.

This description of the nested Code element does not match proposed schema where
Code is of samlp:SubStatusCodeType.

Is it better to call netsted Code element SubCode, because we already have top level
Code element within status element?

Also, in your example <samlp:Value> and <samlp:Code> (is it nested code?) are children of <samlp:Status>
although proposed schema calls for samlp:Code to be a child of <samlp:Status>:
<samlp:Status>
        <samlp:Code>
                <samlp:Value>...</samlp:Value>
        </samlp:Code>
</samlp:Status>

><samlp:Response>
>  ....
>  <samlp:Status>
>    <samlp:Value>samlp:Receiver</samlp:Value>
>    <samlp:Code>
>      <samlp:Value>samlp:Incomplete</samlp:Value>
>    </samlp:Code>
>    <samlp:Message>Not all the attributes could be obtained.</samlp:Message>
>  </samlp:Status>
></samlp:Response>

Simon G.