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

[Trevor Perrin <trevp@trevp.net>]

At 06:12 PM 10/20/2003 +0200, Juan Carlos Cruellas Ibarz wrote:


>Concerning the verification protocol, I would like that our protocol clearly
>distinguishes in the validation response between two different aspects:
>
>1. Whether the server could successfully process or not the request, arriving
>to a result on which it could report the client.
>
>2. Whether the signature the client sent to verify is valid or not.
>
>
>After reading the core protocol document in its section 2.5, it seems to me
>as if
>the <Status> element does NOT REPORT ON THE STATUS OF WHAT THE
>SERVER WAS REQUESTED TO VERIFY, BUT ON THE STATUS THE SERVER
>HAS REACHED AFTER trying to process that request, and in fact there is no such
>code like valid or invalid ....

I was thinking the <Status> could cover both aspects.  If a status code 
says that the signature is valid or not (2), then that implies (1) - the 
server succesfully processed the request.

It doesn't bother me to re-use the <Status> field for this, it just avoids 
adding a new element, and I don't think this would cause any confusion.

But you're right, we could separate these.  What do other people think?



>I propose to define in the VerifyResponse two elements:
>
>1. Result. This element would substitute the current Status. It would
>indicate the
>global result of the processing, namely, whether the server has
>successfully processed
>or not the request of the client.

<Status> was the name SAML used for its protocols.
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security

Since it's another OASIS XML security protocol, I figure it's a good role 
model, so I'd stick with that name.



>2. A Report element that would contain an Status element indicating whether
>the signature was or not valid, and a number of optional StatusMessages
>that could give more information on how the server has concluded that the 
>signature is
>or not
>valid.

For these optional StatusMessages - I think it would be better to handle 
them through <Options>/<Outputs> - i.e., the client can send certain 
options saying "tell me precise details on what failed, or what checks you 
performed, or send me the CRLs and certs you used, etc.".  If the client 
sends such <Option>s, the server will return the corresponding <Output>s.


Trevor