Conformance Section, a thing of great beauty

OK maybe that overstates the matter. However I think this pretty much
puts the right format out. It avoids the need to say everything three
times.
 
Note that I am taking the view that WSDL allows us to be rather more
restrictive than would otherwise be the case. We can say here are the
requirements for XKMS. If you say that is what you support you have to
be interoperable. However someone who says they do XKMS over DIME could
advertise that in their WSDL and describe it as such in their product
offering and everyone should be happy.
 

Conformance


The section describes features and operations that XKMS applications
whose support is either required or recommended to ensure
interoperability of XKMS services.

As such the conformance requirements fall on message recipients rather
than message senders, although a sender SHOULD NOT send a message unless
it is known that it will be accepted by the recipient.

The following table specifies the conformance requirements of XKMS as
REQUIRED,. RECOMMENDED or OPTIONAL as follows:

*	
If support for a feature is specified as REQUIRED a conforming XKMS
implementation MUST support the use of that feature in a message sent by
by another XKMS implementation.

*	
If support for a feature is specified as RECOMMENDED a conforming XKMS
implementation SHOULD support the use of that feature if used by another
XKMS implementation.

*	
If support for a feature is specified as OPTIONAL, XKMS implementations
SHOULD NOT send messages requiring support for a feature.

Some features as specified as REQUIRED* or RECOMMENDED*. This signifies
that the condition holds if another feature is supported. For example an
XKMS Locate service is not required to support XML Signature. If however
XML Signature is supported the use of Exclusive Cannonicalization MUST
be supported.

One feature is specified as RECOMMENDED +. This signifies that even
though this feature can only be used at the request of the client it is
strongly recommended that the client request use of this feature since a
service is likely to require it for the response to be successful.

Where a service supports a feature that is advertised as OPTIONAL it is
recommended that the service advertise this feature by means of a Web
Service description mechanism. For example an XKMS service that supports
the use of a transport encoding other than HTTP SHOULD advertise that
fact.

Implementers should note that these requirements may change in future
versions of the XKMS specification. For example it is likely that future
versions of the XKMS specification will make the then current version of
the SOAP specification a requirement.


Feature

Operations

Requirement Level

Comments


Operation Support

All

One Operation REQUIRED

A conforming XKMS service MUST support at least one XKMS operation, that
is there MUST be at least one possible input that results in the result
Success.


Compound

OPTIONAL

See note for Status operation support.


Status

RECOMMENDED*

Services SHOULD support status operations if asynchronous processing and
compound requests are also supported 


Operation Response

All

REQUIRED

A conforming XKMS service MUST accept any valid XKMS request sent to it
and be capable of responding to the request with a correctly formatted
XKMS result. If a service does not support an operation it MUST respond
to all requests for a particular operation with the result
Refused.NotImplemented.


Response Mechanisms


Feature

Operations

Requirement Level

Comments


Synchronous Response

All

REQUIRED

A conforming XKMS service MUST be capable of returning an immediate
response to any XKMS request.


Asynchronous Response 

Register, Reissue, Recover

RECOMMENDED+

Processing of certain XKRSS operations may require manual intervention
by an operator in certain circumstances. It is therefore recommended
that clients support the use of asynchronous processing with these
operations unless it is known that all requests will be serviced
immediately.


Compound

RECOMMENDED

Services that support Compound Operations SHOULD support compound
requests 


Locate, Validate,
Revoke

OPTIONAL

Services MAY support Asynchronous responses be supported on these
operations


Pending,
Status

PROHIBITED

A client MAY offer asynchronous processing of Pending and Status
operations however a service MUST NOT return a pending response.


Two-Phase Request

All

RECOMMENDED+

Clients SHOULD support use of the two phase request protocol.


Protocol Encapsulation


Feature

Operations

Requirement Level

Comments


HTTP Transport

All

REQUIRED

Services MUST support the use of HTTP transport


SOAP 1.1 Transport

All

REQUIRED

Services MUST support the use of SOAP 1.1 encapsulation


SOAP 1.2 Transport

All

RECOMMENDED

Services SHOULD support the use of SOAP 1.2 encapsulation


Security Enhancements


Feature

Operations

Requirement Level

Comments


No Security

Locate

REQUIRED

 


[Others]

RECOMMENDED

 


Payload Authentication I

All

RECOMMENDED

 


Payload Authentication II

All

RECOMMENDED

 


TLS Binding I

All

RECOMMENDED

 


TLS Binding II

All

RECOMMENDED

 


TLS Binding III

All

RECOMMENDED

 


Exclusive Canonicalization

All

REQUIRED*

If XML Signature is used, Exclusive Cannonicalization MUST be supported.