The more I think about this, the more the right answer seems
obvious. The notion of a client signing a whole Atom entry is just
fundamentally bogus, because some parts of it are actually owned by
the server (id, update-timestamp). On the other hand, the notion of
a client signing the payload (title/author/categories/summary/
content) is interesting and worth exploring. Fortunately, Atom & APP
are flexible enough that anyone can try a few things out without
breaking any implementations. Unfortunately, nobody has ever
implemented anything like this that I know of, and I don't even know
of any applications that need it, so it''s *way* too early to try to
specify The Right Thing To Do.
So.... I would address Sam's points like so:
Expand 15.5 to point out all the problems that have emerged in this
discussion and which make client-originated dig-sig a non-starter for
APP. Further point out that server-side dig-sig, per RFC4287 rules,
might make all sorts of sense in certain apps and is perfectly
technically feasible; I now think it's a bug that the spec leaves you
with the impression that something about server-side digsig might not
work. Further point out that signature elements can freely be
inserted in to-be-posted entries by clients and are guaranteed not to
break the server because of our MustIgnore rule, and make it clear
that the door is open to payload signing.
The idea is that down the road, when there's a body of experience and
we know what the Best Practices are, someone can spec an APP
Extension to capture them. -Tim
