RE: Issue 33... keybinding discuss...

I'm in agreement with you on client-server interactions.  The service
provides a client the best info it has at the time of a request.  There
is no obligation, nor any defined way, for the service to inform clients
something has changed at a later time.  Clients only learn of the new
status by issuing another request.

As for the service's responsibilities in regards to tracking actions
within some backend PKI, I believe Phill's trying to capture the idea
that an XKMS service which states that its information reflects the
current status of some PKI system should actually track the status of
certs in that PKI system.  I don't see how the XKMS spec can define any
specific behaviors in this area.  But, we can suggest that useful
services will implement behaviors that meet reasonable expectations for
the correspondence between info the service outputs and whatever backend
system it relies upon.

-----Original Message-----
From: Joseph Reagle [mailto:reagle@w3.org] 
Sent: Wednesday, October 16, 2002 2:04 PM
To: Blair Dillaway; Hallam-Baker, Phillip; Www-Xkms (E-mail)
Subject: Re: Issue 33... keybinding discuss...


On Wednesday 16 October 2002 04:43 pm, Blair Dillaway wrote:
> So, it might it be better to say "... cert is revoked by any means 
> then the KeyBinding status would become Invalid"?

That's better for me but I'm still a little uncomfortable with the "by
any 
means." Does this mean the XKMS service has an obligation to keep track
of 
revocation lists at all times, and if it notes a revocation on a
previously 
valid keybinding update the client? The way I thought it worked was that
a 
response to a Validate request was a contemporaneous statement about the

status at *that* time. If a CR is issued, and I encounter it during a
path 
validation, the next time the request is issued, the status would of
course 
not be the same. But this isn't any special sort of processing...

Received on Wednesday, 16 October 2002 17:13:43 UTC