<Result>/<ResultMinor> more values vs appropriate modelling [Action05-11-28-04]

[Konrad Lanz <Konrad.Lanz@labs.cio.gv.at>]

Dear Tommy and all,

The status quo (committee draft 3) concerning the <Result> element 
returned in a <SignResponse> or <VerifyResponse> is as follows:

The <Result>/<ResultMajor> indicates whether processing was a success 
(urn:oasis:names:tc:dss:1.0:resultmajor:Success) and the server was able 
to return a response that either carries a signature in a <SignResponse> 
or a statement about the validity of a signature (timestamp).
If processing was not successful the server responds with a 
(urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError) if it could 
determine that the processing error occurred due to a malformed request 
or inconsistent data sent by the client otherwise a ResponderError 
(urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError) is returned 
assuming that the failure was caused by the server.

The <Result>/<ResultMinor> currently offers a set of values for 1. 
successful processing and 2. erroneous processing. (I numbered them to 
ease the discussion. Profile editors are welcome to contribute further 
<ResultMinor> values as this will enable a broader view on the issue). 
1. can be further divided in sign (1.1) and verify (1.2) specific 
<ResultMinor> values however there are currently none for the sign 
request. 1.2 can be divided in valid signature/timestamp (1.2.1) 
responses, invalid signature/timestamp (1.2.2) responses and 
indeterminable signature (1.2.3) responses.

1.2.1.1 urn:oasis:names:tc:dss:1.0:resultminor:ValidMultiSignatures
1.2.1.2 
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:onAllDocuments
1.2.1.3 
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:onTransformedDocuments
1.2.1.4 
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:notAllDocumentsReferenced

1.2.2.1 
urn:oasis:names:tc:dss:1.0:resultminor:invalid:refencedDocumentNotPresent
1.2.2.2 urn:oasis:names:tc:dss:1.0:resultminor:invalid:indeterminateKey
1.2.2.3 urn:oasis:names:tc:dss:1.0:resultminor:invalid:untrustedKey
1.2.2.4 urn:oasis:names:tc:dss:1.0:resultminor:invalid:incorrectSignature
1.2.2.5 urn:oasis:names:tc:dss:1.0:resultminor:inappropriate:signature

1.2.3 
urn:oasis:names:tc:dss:1.0:resultminor:indetermined:checkOptionalOutputs

2.1 urn:oasis:names:tc:dss:1.0:resultminor:NotAuthorized
2.2 urn:oasis:names:tc:dss:1.0:resultminor:NotSupported
2.3 urn:oasis:names:tc:dss:1.0:resultminor:NotParseableXMLDocument
2.4 urn:oasis:names:tc:dss:1.0:resultminor:XMLDocumentNotValid
2.5 urn:oasis:names:tc:dss:1.0:resultminor:XPathEvaluationError
2.6 urn:oasis:names:tc:dss:1.0:resultminor:MoreThanOneRefUriOmitted

1.2.3 The introduction of 1.2.3 became necessary as <ds:Manifest> (cf. 
http://www.w3.org/TR/xmldsig-core/#sec-o-Manifest 
<http://www.w3.org/TR/xmldsig-core/#sec-o-Manifest> and 
http://www.w3.org/TR/xmldsig-core/#sec-Manifest) mandates that 
applications may reserve reference validation decision logic to themselves.
In our case this means that only clients will be able to decide upon 
validity themselves, based on the information given in 
<VerifyManifestsResults>. Note that this is only relevant if the 
optional input <VerifyManifests> was sent as and <ds:Manifest> are 
treated as normal documents otherwise.

Considering all values above it has to be noted that the <ResultMinor> 
is not limited to core validity of XMLDsig signature verification even 
not if resultminor would only take the values starting with 1.2.

There is a need to discuss the relations between <ResultMinor>, 
<ProcessingDetails> and <VerifyManifestsResults>.

My feeling is that a lot of things dealt with in <ResultMinor> should be 
rather in <ProcessingDetails>. I also think that <ProcessingDetails> 
should be rather called <ValidationDetails> as it seems that would 
reflect what they really are. And <VerifyManifestResults> should be 
merged into it.

So we could and should limit <ResultMinor> to

1.2.1 urn:oasis:names:tc:dss:1.0:resultminor:valid
1.2.2 urn:oasis:names:tc:dss:1.0:resultminor:invalid
1.2.3 
urn:oasis:names:tc:dss:1.0:resultminor:indetermined:checkOptionalOutputs

and leave values 2.1 - 2.6 as they are.

The only and probably more sensible alternative would be to abandon the 
values starting with 1 and to limit <ResultMinor> to add more verbosity 
to unsuccessful processing. On the other hand we should elaborate 
<ValidationDetails> (<ProcessingDetails>) to a compulsory output element 
for <VerifyRequst> and model the validation verbosity level inside 
<ValidationDetails>.

To conclude, I think the introduction of more <ResultMinor> values will 
cause that we leave the route of designing an xml protocol and we would 
start to model structure inside URNs.

best regards
Konrad

This mail is related to Action [05-11-28-04]

P.S.: I think I mentioned previously already that 1.2.1.3 
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:onTransformedDocuments 
should be abandoned because the client does not specify transforms on a 
verify request and a server only performs the transforms inside 
<ds:Reference>/<ds:Transforms>.