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

[Juan Carlos Cruellas Ibarz <cruellas@ac.upc.es>]

Trevor,

First of all, I agreee that the proposal I made was breaking the
core-options separation,
specially when speaking of the Reports... What I have in mind (and I did
not make clear
in that message) is that these Reports can be part of the Options... sorry
about that.
I tried to illustrate that we should define as part of the Options a
Reports mechanism
that could give different levels of information....

Second, I agree with the fact that the first level of our protocol has this
architecture:
some required elements and an Options element containing all the options.
 Now, where I think we disagree is on the extent of the Status element...

>
>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?
>
I see: you leave to the client the responsability of taking note of that
fact...

>
>
>That was just following SAML.
>
I have seen that XKMS does also use it

>>
>><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>
>>

Do you agree in that these situations deserve some coding?

>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:

I would not call that re-using, but enlarging its semantics. IF you 
still see Status as an element without inner structure, ie, one
whose value is a QName from a repertory I think that we are mixing two
different
meanings.....For me re-using is to take a previously defined element and 
using it as part of a new structure keeping its semantics...

I do not like very much tags that seem to say something and in fact contain
two types of information.
Generally speaking, when somebody mentions "status" in a verification process
I always think in the status of a certificate or whether the signature is
valid or not,
unless the "status" is followed by something like "the server has reached".

So, I contend that we should clearly separate both issues, in different
elements:

1. Whether the server could process the request of the client.
2. Whether the server found valid or unvalid the signature.

Because they are denoting completely different things and in consequence
they can fire in the client's side completely different actions!!!

I propose you the following:

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

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


And then define a Result having two different elements:
<xs:element name="Result" type="ResultType"/>
<xs:complexType name="ResultType">
	<xs:sequence>
		<xs:element ref="ServerProcessingResult">
		<xs:element ref="Status" minOccurs="0">
	<xs:sequence/>
</xs:complexType>

---> I am using named types just because I remember better the 
syntax...

Now, both elements would have a different repertory of predefined values, the
symmetry would remain at the first level, the tags would be better aligned
with their
contents and different informations would appear in different places...

Juan Carlos.

>

>Trevor 
>