On Jun 17, 2007, at 1:51 PM, James M Snell wrote:
One way to do client signing in the future is for clients to start by
POSTing signed entries. If this is how it is likely to work in the
future, then today we probably want to decide what "older" servers
should do in the future -- reject signed entries, accept them
unchanged
and still signed (unlikely), strip the signature or invalidate the
signature.
Another way to do client signing in the future is for clients to POST
unsigned entries, allow the server to assign timestamps and
atomIDs and
make other changes, and then sign the result. The server could allow
PUT or some other mechanism to overwrite an unsigned entry with a
signed
entry provided that the server-controlled content remains the same
(need
to think about updated value, of course). If this is the way we
expect
things to work in the future, then there's less interop
requirements to
think about today.
What exactly are you trying to achieve with this?
Trying to figure out if there are any additional requirements or
decisions or clarifications to make now, that would make design and
interoperability much easier when (if) a group gets around to
standardizing a way to do client signatures. It's not worth much
work now (present value of money/time and all that) but it's worth a
bit of thought.
Lisa
