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.
