[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: <Result>/<ResultMinor> more values vs appropriate modelling [Action 05-11-28-04]
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>.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]