Right, that point-in-time quality is what makes this attribute most useful... it does not, however, make this a reliable integrity check. The attribute allows a feed producer to describe the state of the resource at the time the link was created... which is definitely something that has been missing to this point. This becomes even more important when combined with digital signature scenarios. That said however, it has to be acknowledged that these hash digests simply are not authoritative enough to be used as a reliable integrity check for the resource at the time a consumer may retrieve it.
On Mon, May 17, 2010 at 2:00 PM, Bob Wyman <[email protected]> wrote: > > > On Mon, May 17, 2010 at 4:41 PM, James Snell <[email protected]> wrote: >> >> The key challenge is that the digests contained in the atom:link >> cannot be viewed as being authoritative and only reflect a >> point-in-time value that may only be true for the producer of the Atom >> feed. > > Actually, for the applications that I'm most interested in at the moment, > such "point-in-time" values are exactly what I want. I want to be able to > point to a specific version of a resource and say that if you read something > that I did not, then you're not looking at the same version of the document > that I saw. The best example would be something like a contract, petition or > poll that I might "sign" by-reference. My signature would only be "valid" if > the resource linked to is exactly the same as it was at the point in time > when I generated the hash value that I later included in a signed Atom > entry. > bob wyman > >> >> There are many factors which influence whether the same hash >> value can be generated for the linked resource. If the hash-value >> happens to match... fantastic. If the hash-value doesn't match, then >> the feed consumer knows that they need to do more work to figure out >> what happened... including performing a more authoritative check of >> the resource. >> >> >> On Mon, May 17, 2010 at 1:18 PM, Bob Wyman <[email protected]> wrote: >> > I'm curious about the vigor with which you seem to be denying the >> > utility of >> > hash functions in integrity checking when you write: >> > >> > hash attribute values MUST be considered to be strictly advisory and >> > cannot >> > be used reliably as an end-to-end integrity check. >> > >> > I am, of course, aware of the limitations of both hash functions and >> > end-to-end links, but it seems to me that the real risk here is limited >> > to >> > false-negatives. (i.e. If hash values don't match, I can't really be >> > sure >> > that I haven't linked to the correct resource.) However, it seems like >> > the >> > risk of false-positives is no greater than in any other hash-based >> > system. >> > (i.e. if the hash values do match, then I've can be reasonably, but not >> > completely, assured of integrity.) >> > I think I understand the standard issues. Is there something more exotic >> > that I'm missing? >> > bob wyman >> > >> > On Mon, May 17, 2010 at 3:47 PM, James Snell <[email protected]> wrote: >> >> >> >> Ok, draft is updated with the new syntax for the hash attribute. >> >> >> >> http://www.ietf.org/staging/draft-snell-atompub-link-extensions-05.txt >> >> >> >> There is also one additional 'media' attribute added. I wanted to wait >> >> to add it until after I was sure the other three attributes were fine. >> >> The 'media' attribute serves the same purpose as the 'media' attribute >> >> on HTML5 links... the value is a media query. For example: >> >> >> >> <link href="foo" media="handheld and (min-width = 20cm)" /> >> >> >> >> The use case is to be able to provide multiple links targeted at >> >> specific types of media... e.g. screen, print, mobile devices, etc. >> >> >> >> Another change that I am contemplating making is introducing a new >> >> child element for the atom:link element that would allow it to serve >> >> the same basic purpose as the GData feedLink and entryLink elements >> >> except with greater flexibility... specifically, it would allow a >> >> representation of the linked resource to be dropped directly into the >> >> link element, e.g. >> >> >> >> <link rel="alternate" href="foo" type="text/plain"> >> >> <data type="text">this is a representation of the data</data> >> >> </link> >> >> >> >> <link rel="alternate" href="foo" type="image/jpeg"> >> >> <data type="encoded">abc...def==</data> <!-- base64 --> >> >> </link> >> >> >> >> <link rel="alternate" href="foo" type="application/atom+xml"> >> >> <data type="markup"> >> >> <feed>...</feed> >> >> </data> >> >> </link> >> >> >> >> Or something along those lines. >> >> >> >> Thoughts? >> >> >> >> - James >> >> >> >> On Sun, May 16, 2010 at 10:44 PM, Peter Keane <[email protected]> >> >> wrote: >> >> > On Sun, May 16, 2010 at 11:00 PM, Sam Johnston <[email protected]> wrote: >> >> >> Are the commas earning their keep? If they're unnecessary then >> >> >> remove >> >> >> them, >> >> >> otherwise LGTM. >> >> >> Sam >> >> > >> >> > I was going to ask the same question. (re: the commas) >> >> > >> >> > --peter >> >> > >> >> >> >> >> >> On Mon, May 17, 2010 at 7:36 AM, Bob Wyman <[email protected]> wrote: >> >> >>> >> >> >>> +1 LGTM >> >> >>> >> >> >>> On May 16, 2010 11:29 PM, "James Snell" <[email protected]> wrote: >> >> >>> >> >> >>> Ok, although I seriously dislike having to do additional parsing on >> >> >>> attribute values, the arguments made so far are valid and parsing >> >> >>> hex >> >> >>> encoded hash digests is -- fortunately -- quite simple to do. So >> >> >>> let's >> >> >>> go with the following syntax... >> >> >>> >> >> >>> hash = attribute hash { hash-list } >> >> >>> hash-list = # ( token ":" 1*HEX ) >> >> >>> >> >> >>> The token and HEX productions are defined by RFC2616... >> >> >>> >> >> >>> The spec would defer to the existing IANA registry for hash >> >> >>> functions >> >> >>> to define the "tokens" >> >> >>> >> >> >>> This would result in a syntax of... >> >> >>> >> >> >>> hash="md5:abc...xyz, sha-1:123...567, sha-512:xyz...abc" >> >> >>> >> >> >>> This seem acceptable to everyone? >> >> >>> >> >> >>> - James >> >> >>> >> >> >>> On Sat, May 15, 2010 at 11:46 PM, Sam Johnston <[email protected]> >> >> >>> wrote: >> >> >>> > James, >> >> >>> > In consideration o... >> >> >> >> >> > >> >> >> >> >> >> >> >> -- >> >> - James Snell >> >> http://www.snellspace.com >> >> [email protected] >> > >> > >> >> >> >> -- >> - James Snell >> http://www.snellspace.com >> [email protected] > > -- - James Snell http://www.snellspace.com [email protected]
