Re: Proposed new schema

A few comments on the schema:

1) REPLACE
<element name="RespondWith" type="QName"/>
WITH
<element name="RespondWith" type="RespondWithEnumType"/>

2) REPLACE
<complexType name="ResultAbstractType" abstract="true">
  ...
    <attribute name="ResultMinor" type="QName" use="required"/>
  ...
 </complexType>
WITH
<complexType name="ResultAbstractType" abstract="true">
  ...
    <attribute name="ResultMinor" type="xkms:MinorResultCodeEnumType" use="required"/>
  ...
 </complexType>

3) Now that we have added TransactionID as an attribute of MessageAbstractType,
we should get rid of it as an attribute of KeyBindingType. We should also get rid of:
<element name="TransactionID" type="string"/>

4) What is the purpose of the "ID" attribute which is part of KeyBindingType.
Can we get rid of this now:
<attribute name="ID" type="ID" use="optional"/>

-Yassir.

"Hallam-Baker, Phillip" wrote:

> All,
>
>         Attached is a somewhat revised schema, the major changes are:
>
> 1) Use of Qnames for all enumerated items
>         I am somewhat uncertain of the application of the Qnames mechanism,
> for example should we link to the qnames defined in other specs, should we
> use our own enumeration, how does the extension mechanism work? In general
> the case we have is that we want to define a set of basic codes but allow
> for extensibility.
>
> 2) Message abstract type introduced
>         This is the point where we define the transaction ID, signature
> semantics etc. It is also the place where we should have a description of
> the abstract processing semantics when using payload security.
>
> 3) Reason code moved to Keybinding
>         where is bellonged (see earlier message)
>
> Some open issues
>
> 1) The Pending Response.
>         The client should have a mechanism for stating that it will accept a
> pending response. [NB this will absorb even more of Bulk into XKMS]. I
> suggest a RespondWith Qname Pending.
>
>         If the client proposes Pending then IMHO there should be an optional
> mechanism to specify a notification mechanism on completion (c.f. the AST
> mechanism of VMS which was the main reason the VMS systems consistently beat
> UNIX systems on transaction processing benchmarks even with slower
> hardware). This needs to be essentially open as we don't really want to have
> to specify the notification protocol, and in many cases this will be
> something like an email message is sent. I suggest something like a
> method/port pair of URIs similar to what we do in UseKeyWith.
>
>         Introducing this section would allow closure of many of the
> questions pending on pending.
>
> 2) Precise signing profile
>         I believe that what we want to specify is that the signature is
> enveloped and that the scope is the entire message node with the exception
> of the signature itself.
>
> 3) Denial of Service Protection / Replay attack
>         Do we need to consider these?
>
>         If we do I think we need to introduce an optional 2 phase protocol
> as follows (looking at the Client FSM):
>
> State Initial
>         Transition !Request Waiting
>                 // Send out initial request to service
>                 // Go to state Waiting
>
> State Waiting
>         Transition ?Response.Complete Completed
>                 // Service is not in DoS state and does not care
>                 // about replay attack
>         Transition ?Response.Represent Represent
>                 // Service requires the request to be represented
>                 // together with an authentication nonce
>         Transition ?ANY Fail
>
> State Represent
>         Transition !Request Waiting
>                 // Represent request to service together with nonce
>
> State Waiting2
>         Transition ?Response.Complete Completed
>         Transition ?ANY Fail
>
> State Completed
>         Terminal
>                 // We Won 8=)
>
> State Fail
>         Terminal
>                 // We Lost :-(
>
> The nonce is cryptographically bound to the request so that the service can
> quickly determine if the nonce presented is valid and corresponds to the
> given request (cf JFK).
>
> Ideally the nonce would be bound into the represented request.
>
> Looking to the future this is exactly the type of facility that we would
> want to see bound into the Web Services security layer and into WSDL.
>
> I would like the WSDL to tell me the following facts about the service
> 1) The public key of the service
> 2) The encapsulation formats the service supports
>         [e.g. ws-security, TLS, IPSEC, payload etc.)
> 3) If a key agreement service is available / must be used
> 4) If 2 phase DoS protection is available / must be used
>         the level of authentication required on the 1st, second message
>
> If I know in advance that the service is definitely going to do DoS
> protection then I probably don't want to send a signature on the first
> request, in fact I might only want to send a hash of the request.
>
> Clearly this level of protection is something that we might say should be
> pushed down into the XP/SOAP layer and can be defered. It would certainly be
> simpler to deal at that level since it would be easier to do this type of
> processing with a detached signature in a SOAP header. That way the
> signature can consist of a pretty simple manifest with clean semantics and
> not need to worry about the complexity of enveloped processing.
>
> On the other hand folk might reasonably expect XKMS to provide for DoS and
> Replay attack protection.
>
>                 Phill
>
> Phillip Hallam-Baker FBCS C.Eng.
> Principal Scientist
> VeriSign Inc.
> pbaker@verisign.com
> 781 245 6996 x227

Received on Thursday, 28 March 2002 14:43:48 UTC