Re: Manifest validation

[Tommy Lindberg <tommy.lindberg@gmail.com>]

Hi Konrad -

It looks good to me, based on my understanding that there will only be
a single document containing XML Signature(s) in any one VerifyRequest.

> It also causes the<ProcessingDetails> optional output to be returned giving
> information about signature core validation.

I had expected that the return of <ProcessingDetails> would still
have required the client to indicate this through
<ReturnProcessingDetails>.  I also think it is questionable,
exactly what additional useful processing detail (well, perhaps URI
dereferencing problems, algorithm support issues) than "refererence
failed" (which is already part in ManifestResult/@Status) could be
conveyed in case of Manifest validation - in general, the core does not
specify any values for the Code attribute so the only thing that
remains is the Message element intended for a free text description.

If <ProcessingDetails> is to be enhanced for conveying a Manifest
specific validation detail then a new value for the Type attribute is
probably in order; considering the current value space, perhaps
urn:oasis:names:tc:dss:1.0:detail:Manifest.

> the result - either valid or invalid.

Only to be used as values to the Status attribute:

urn:oasis:names:tc:dss:1.0:manifeststatus:Valid
urn:oasis:names:tc:dss:1.0:manifeststatus:Invalid

Regards,
Tommy

On 10/4/05, Konrad Lanz <Konrad.Lanz@iaik.tugraz.at> wrote:

Dear all,

These are the necessary changes to verify manifests and to give feedback
to a client application. Tommy can you please check I haven't forgot
anything.

If someone supplies the optional input <VerifyManifests> the optional
output <VerifyManifestResults> is
returned indicating the status of the verification. It also causes the
<ProcessingDetails> optional output to be returned giving
information about signature core validation.

Further the service will always respond in such a case with the
following ResultMinor.
The client (client application) will have to determine how to interpret
the result - either valid or invalid.

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

<xs:element name="VerifyManifestResults"
type="dss:VerifyManifestResultsType"/>
<xs:complexType name="VerifyManifestResultsType">
  <xs:sequence>
    <xs:element ref="dss:ManifestResult" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

<xs:element name="ManifestResult">
  <xs:complexType>
    <xs:element name="ReferenceXpath" type="xs:string"/>
    <xs:element name="Status" type="xs:anyURI"/>
  </xs:complexType>
</xs:element>

An XPath expression is used to identify the Manifesto's Reference for
which the validation status is reported.
The status (Status) contains a URI that indicates the validation outcome
- valid or invalid.

The ResultCodes for verification responses shall be changed to the
following:

urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:onAllDocuments
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:onTransformedDocuments
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:notAllDocumentsReferenced
urn:oasis:names:tc:dss:1.0:resultminor:invalid:refencedDocumentNotPresent
urn:oasis:names:tc:dss:1.0:resultminor:invalid:indeterminateKey
urn:oasis:names:tc:dss:1.0:resultminor:invalid:untrustedKey
urn:oasis:names:tc:dss:1.0:resultminor:invalid:incorrectSignature
urn:oasis:names:tc:dss: 1.0:resultminor:inappropriate:signature
and eventually
urn:oasis:names:tc:dss:1.0:resultminor:indetermined:checkOptionalOutputs

best regards
Konrad