Re: Link Extensions. Need "md5" or some kind of hash.

As some are aware, some of us have been working on the Salmon protocol and specifically on Salmon "Magic Signatures" which are an attempt to provide a very simple mechanism for signing content without losing too many of the benefits of the older, more complex methods. The Magic Signature draft specifically addresses the signing of Atom Entries used with Salmon and, in most cases, there is an implicit assumption that the "content" of the entries will be essentially "pass by value" or, in other words, included within the Magic Signature itself. The problem I've got is that there are times when "pass by ref" makes a great deal more sense. The signed object might be very large, might have security or copyright constraints that make copying difficult, etc. So, I'd like to use the "src" attribute to point to a remote resource and then to use a hash function to essentially pull the remote data into the scope of the signature. For this, I need to be able to specify the specific version of the resource pointed to. (The version is, of course, implicit when I pass by value -- by embedding the signed data in the Magic Signature.)

bob wyman

On Tue, May 4, 2010 at 3:08 PM, James Snell <jasnell@xxxxxxxxx> wrote:

I've noticed that Google has actually started using an etag attribute
in their API which has roughly the same concerns about binding, etc.
I'm a big fan of including as much metadata as practical possible
without going overboard and think that a hash attribute (or set of
hash attribute options not limited to md5) would be a good thing in
general. I've been starting to dust off a few of the old I-D's this
week starting with the tombstones draft (again) so perhaps I'll also
pull out that link extensions draft and give it a do-over.

- James

On Tue, May 4, 2010 at 11:57 AM, Peter Keane <pkeane@xxxxxxxxxxxxxxx> wrote:
>
> On Tue, May 4, 2010 at 12:54 PM, Bob Wyman <bob@xxxxxxxx> wrote:
>> I find that I have a real need for the "md5" Link rel mechanism defined in
>> James Snell's old Atom Link Extensions draft or something functionally
>> equivalent. Basically, what I need to do is ensure that the "src" attribute
>> on an atom.content element is pointing to a known version of a resource
>> rather than simply to any resource that has the same URL as in the src
>> attribute. I'm then going to sign the Atom entry that contains this "by ref"
>> content element.
>
> There have been a number of discussion of such in the past on
> atom-syntax -- usually focussed on James Snell's link extension draft.
> You might also look at the Atom-Media extensions that came out of
> activity streams work [1] -- no md5, but that'd be an obvious
> addition. I think the MediaRSS spec is widely used, and it does have
> an md5 as a <media:hash> element w/ @algorithm [2]. When I have had
> need for it, I generally used a locally name-spaced attribute on
> atom:link, although that's obviously a sub-optimal solution.
>
> The RESTful implications of such a use are (I think) somewhat
> interesting. It creates a tight-binding (early binding) that is
> somewhat at odds w/ the late-binding nature of REST. I think that's
> why attributes on atom:link are always "advisory" and overridable (see
> RFC4287 sec. 4.2.7.3 and 4.2.7.6) by what's actually at the end of the
> wire. Another (probably impractical) approach is to have the resource
> as actual content instead of just a link.
>
> --peter keane
>
> [1] http://martin.atkins.me.uk/specs/atommedia
> [2] http://video.search.yahoo.com/mrss
>
>
>> I've looked at the HTML5 RelExtentions Wiki but don't see anything there
>> that looks like it does the job.
>> Has anyone else needed hashed links in Atom? If so, what approach did you
>> use to provide them? Is anyone aware of plans to introduce an "md5" or
>> equivalent attribute to the HTML5 list?
>> bob wyman
>>
>
>

--
- James Snell
http://www.snellspace.com
jasnell@xxxxxxxxx