[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] Core protocol: is the <Status> element the status of what has been validated ?
Trevor > >But you're right, we could separate these. What do other people think? Then I propose the following general structure that I have taken from the document in catalan that I submitted some time ago, with some changes.... You have to take into account that named types were used, but the objective is to show up a proposal for initial structure: <xs:complexType name="ValidationResponseType"> <xs:sequence> <xs:element ref="ValidationResult"/> <xs:element name="RefDateTime" type="xs:dateTime" minOccurs="0"/> <xs:element ref="Reports" minOccurs="0"/> </xs:sequence> <xs:attribute name="id" type="xs:ID" use="optional"/> </xs:complexType> The RefDateTime would represent the time for which the server could report to have verified the signature (which not has to be necessarily the time when the request was sent -by the way, do we allow to indicate that particular issue in the core?) In that structure ValidationResult reports: 1. A value indicating whether the processing was successfully completed... 2... and if not, an error code indicating the reasons why it was not completed with success. Its schema could be something like: <xs:element name="ValidationResult" type="ValidationResultType"> <xs:complexType name="ValidationResultType"> <xs:sequence> <xs:element name="Value" type="ResultValueType"/> <xs:element name="CodeError" type="CodeErrorType" minOccurs="0"/> </xs:sequence> <xs:attribute name="requestRef" type="xs:string" use="optional"/> </xs:complexType> For the values and the error codes, I have thought in strings, but you propose QNames...and I agree with that, Below follow some codes as strings, that we could use for our QNames, and that were already identified when the protocol I mentioned at the begining of the message was specified. <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> I suggest to define QNames accordingly for these codes. The minimal version of Reports element should have: . An indication of valid or invalid for the signature (it could be an attribute). . A Report indicating what gone wrong in the verification, ie, what certificate was found revoked, etc. A less minimal version of Reports element could have: . An indication of valid or invalid for the signature . A list of reports, for instance one per each certificate validated Juan Carlos.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]