James, Breathing life back into the draft would be greatly appreciated. At the risk of boring people, I'd like to expand a bit more on what I'm trying to accomplish. There might be other things that I've missed...
As some are aware, some of us have been working on the Salmon<http://www.salmon-protocol.org/>protocol and specifically on Salmon "Magic Signatures<http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html>" 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.) What I'm looking for is something that I might use in much the same way that I would use an "artifact<http://en.wikipedia.org/wiki/SAML_2.0#Artifact_Format>" in SAML. I realize that I could just adopt the SAML method, but, I'm attracted by the idea that an Atom based system may not need to do what SAML did in inventing a whole different datastructure for use when signing data by-ref. bob wyman On Tue, May 4, 2010 at 3:08 PM, James Snell <[email protected]> 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 <[email protected]> > wrote: > > > > On Tue, May 4, 2010 at 12:54 PM, Bob Wyman <[email protected]> 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 > [email protected] >
