OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[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]