W3C home > Mailing lists > Public > www-xkms@w3.org > March 2002

Overuse of KeyBindingType

From: Yassir Elley <yassir.elley@sun.com>
Date: Fri, 08 Mar 2002 17:06:22 -0500
Message-ID: <3C8935DE.912BB99@sun.com>
To: www-xkms@w3.org
KeyBindingType is used in both the ValidateRequest and the ValidateResponse.
This is somewhat forced since some of the elements of KeyBindingType don't
make sense for the ValidateRequest (such as status, which will always be valid implcitly, as Joseph
pointed out). Other elements, such as ValidityInterval and KeyUsage could make sense (i.e. the
client is requesting the service to find a key that has the specified KeyUsage or that that is valid
during the specified ValidityInterval), but it is unclear whether they are there just as hacks (such
as Status), or whether they are actually meant to be there. In any case, we need additional text
specifying exactly what is meant by a ValidateRequest. I must say that Joseph's query approach
certainly makes it clearer (to me) and more explicit what is going on in the Request.

Additionally, the KeyBindingType is also used with
{Register,Reissue,Revoke,Recover}Request/Response. This is also awkward
because it forces us to include the PassPhrase element in KeyBindingType, even
though this will never be used with the ValidateRequest/Response (right?). I realize that
many of these elements are optional, but it is just confusing the way it is now.

If all of these Requests and Responses do indeed use some of the same data that we
don't want to bother duplicating, we should
create another abstract type (KeyBindingAbstractType?) that can be extended (or even a non-abstract
type that can be included) that contains common elements, and have additional
elements that are specific to a particular kind of request or response be included in the
declaration of that request or response.

By the way, I noticed we have a catch-all called ProcessInfoType. We should include
some text giving an example use of this. Can someone give a compelling example of its

Received on Friday, 8 March 2002 17:09:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:38 UTC