At 2:15 PM -0700 6/20/05, James M Snell wrote:
The spec already allows enveloped XML signatures for the document. Question: should we only allow signing of the entire document or are there valid use cases for allowing each individual entry in the feed to be individually signed?
There are many valid use cases for both: that's why the spec explicitly allows both.
I'm quite happy with limiting it to the first as I don't really see much of a reason to support the second and third examples, but wanted to see if anyone had any opinions or use cases that could justify the ability to independently sign individual entries within a feed.
The spec uses MAY for the conformance criteria, so no one has to support either.
At 9:17 PM -0700 6/20/05, James M Snell wrote:
In other words, if the entry in the first example above were to be included in an aggregate feed containing entries from multiple authors, the <author /> element from its containing feed would need to be added to the entry element's collection of metadata... (<entry>...</entry> becomes <entry> .. .<author /> ... </entry>) thereby invalidating any signature calculated over the entry.
Fully disagree. No one is *forced* to add the collection of metadata to the entry. You give a very good reason why someone would not want to.
One would also have to contend with the potential problems introduced by namespace declarations with the feed. The bottom line of this is that an entry with a signature could not simply be copied over to a new containing feed element with the signature in tact making the aggregator scenario unworkable.
Again, fully disagree. It is quite reasonable to pass along signed entries without changing them.
So... given all this... I think I'm gong to make an assertion and open that assertion up for debate: The need for an end-to-end trust model for Atom capable of traversing any number of intermediaries is largely a myth.
How can we debate that before businesses have had a chance to create their models?
What is really needed is a simple mechanism for protecting feeds against spoofed sources (e.g. man-in-the-middle serving up a bogus feed) and for indicating that content is trustworthy* on the document level (as opposed to individual feed entry level). * by which I mean, for example, binary enclosures are trustworthy, the feed itself does not contain any malicious content, etc
This is a very different model than what we chose for Atom. It is possibly an interesting idea, but it isn't Atom.
--Paul Hoffman, Director --Internet Mail Consortium
