Re: Signatures in feeds of Aggregated Entry Documents

[Antone Roundy]

On Sunday, January 9, 2005, at 03:18  AM, Eric Scheid wrote:
sidebar: does the signature technology we use for the atom format 
allow us
to state that certain child elements are not to be included in the 
signature
algorithm. I'm thinking of something along the lines of the 
following...

<feed>
    ...
    <entry>
        <content ... />
        <date ... />
        ... <!-- usual atom:entry elements -->
        <Signature ... />
        <annotation by="pubsub.com">
            <!-- stuff which the atom spec says won't be
                 included in the signature calculation -->
        </annotation>
    </entry>
</feed>
This has come up before[1], but I don't think a Pace was ever 
written--a "not-signed" attribute seemed to be preferred early in the 
discussion.  One drawback vs. a "not-signed" attribute is that 
applications would have to be able to recognize that <annotation>'s 
children belong at the level where the annotation element itself lives. 
 The obvious advantage of <annotation> would be that the annotation 
itself could be signed, a la:

<feed>
    ...
    <entry>
        <content ... />
        <date ... />
        ... <!-- usual atom:entry elements -->
        <Signature ... />
        <annotation by="pubsub.com">
            <Signature ... />
            <!-- stuff which the atom spec says won't be
                 included in the signature calculation for the ENTRY -->
        </annotation>
    </entry>
</feed>
<annotation> could also be useful as a means of tracking where 
annotations to an entry came from.  Only the original publisher might 
be allowed to add data outside of an annotation element.  Applications 
merging entries might do so and put everything outside of annotation 
elements, but they could be required to generate a new ID for the 
entry, thus not asserting that it was an instance of one of the source 
entries.

[1] http://www.imc.org/atom-syntax/mail-archive/msg09534.html