Re: [dss] Core protocol: is the <Status> element the status of what has been validated ?

[Trevor Perrin <trevp@trevp.net>]

At 05:55 PM 10/21/2003 +0200, Juan Carlos Cruellas Ibarz wrote:

>Trevor
> >
> >But you're right, we could separate these.  What do other people think?
>
>Then I propose the following general structure that I have taken from the
>document
>in catalan that I submitted some time ago, with some changes....
>You have to take into account that named types were used, but the objective
>is to show up a proposal for initial structure:
>
><xs:complexType name="ValidationResponseType">
>         <xs:sequence>
>                 <xs:element ref="ValidationResult"/>
>                 <xs:element name="RefDateTime" type="xs:dateTime" 
> minOccurs="0"/>
>                 <xs:element ref="Reports" minOccurs="0"/>
>         </xs:sequence>
>         <xs:attribute name="id" type="xs:ID" use="optional"/>
></xs:complexType>
>
>The RefDateTime would represent the time for which the server could report
>to have verified the signature (which not has to be necessarily the time when
>the request was sent -by the way, do we allow to indicate that particular
>issue
>in the core?)

In the requirements doc (3.7.2) it says "the client may request that the 
signature be verified at a point in the past".  Which sounds like an Option 
on the Verify Request, not the Response.

If the client doesn't send such an Option, I assume the server should just 
validate for the current time.  So do we need to return something like this 
in the response?




>In that structure ValidationResult reports:
>
>1. A value indicating whether the processing was successfully
>completed...
>2... and if not, an error code indicating the reasons why it was not
>completed with success.
>
>Its schema could be something like:
>
><xs:element name="ValidationResult" type="ValidationResultType">
>
><xs:complexType name="ValidationResultType">
>         <xs:sequence>
>                 <xs:element name="Value" type="ResultValueType"/>
>                 <xs:element name="CodeError" type="CodeErrorType" 
> minOccurs="0"/>
>         </xs:sequence>
>         <xs:attribute name="requestRef" type="xs:string" use="optional"/>
></xs:complexType>

What's the requestRef?

I'd rather have a <Status> element for this that could be re-used for both 
the signing and verifying protocols, and use the same child element names 
that SAML does (<StatusCode>, <StatusMessage>).


>For the values and the error codes, I have thought in strings, but you
>propose QNames...and I agree with that,

That was just following SAML.


>Below follow  some codes as strings, that we could use for our QNames, and
>that were already
>identified when the protocol I mentioned at the begining of the message was
>specified.
>
><xs:simpleType name="ResultValueType">
>         <xs:restriction base="xs:string">
>                 <xs:enumeration value="Success"/>
>                 <xs:enumeration value="Failure"/>
>                 <xs:enumeration value="Refused"/>
>         </xs:restriction>
></xs:simpleType>
>
><xs:simpleType name="CodeErrorType">
>         <xs:restriction base="xs:string">
>                 <xs:enumeration value="InternalError"/>
>                 <xs:enumeration value="UntrustedToken"/>
>                 <xs:enumeration value="UnrecognizedToken"/>
>                 <xs:enumeration value="UserNoAuthorized"/>
>                 <xs:enumeration value="Request error"/>
>         </xs:restriction>
></xs:simpleType>
>
>I suggest to define QNames accordingly for these codes.
>
>The  minimal version of Reports element should have:
>
>         . An indication of valid or invalid for the signature (it could be an
>attribute).
>         . A Report indicating what gone wrong in the verification,
>ie, what certificate was found revoked, etc.
>
>A less minimal version of Reports element could have:
>         . An indication of valid or invalid for the signature
>         . A list of reports, for instance one per each certificate validated

I still kinda like re-using the <Status> to say whether the signature 
succeeded or failed.  It just gives a nice symmetry to things.  Both the 
Sign and Request protocols send <Options> and receive <Status> and 
<Outputs>, and the only difference is that the sign protocol receives a 
<Signature>, and the verify protocol sends one:

<xs:element name="SignRequest">
         <xs:complexType>
                 <xs:sequence>
                         <xs:element ref="dss:Options" minOccurs="0"/>
                         <xs:element ref="dss:InputDocuments"/>
                 </xs:sequence>
         </xs:complexType>
</xs:element>

<xs:element name="SignResponse">
         <xs:complexType>
                 <xs:sequence>
                         <xs:element ref="dss:Status"/>
                         <xs:element ref="dss:Signature" minOccurs="0"/>
                         <xs:element ref="dss:Outputs" minOccurs="0"/>
                 </xs:sequence>
         </xs:complexType>
</xs:element>

<xs:element name="VerifyRequest">
         <xs:complexType>
                 <xs:sequence>
                         <xs:element ref="dss:Options" minOccurs="0"/>
                         <xs:element ref="dss:Signature" minOccurs="0"/>
                         <xs:element ref="dss:InputDocuments"/>
                 </xs:sequence>
         </xs:complexType>
</xs:element>

<xs:element name="VerifyResponse">
         <xs:complexType>
                 <xs:sequence>
                         <xs:element ref="dss:Status"/>
                         <xs:element ref="dss:Outputs" minOccurs="0"/>
                 </xs:sequence>
         </xs:complexType>
</xs:element>


Trevor