RE: XML Digital Signatures in Atom feeds and entries
James, There is an interop service for Atom 1.0 feed/entry signature validation available (with source code for both service and Wordpress plugin) as part of the Signed Ping initiative at http://signedping.com Let me know if you need more info. -Hans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James M Snell Sent: Monday, September 04, 2006 12:02 PM To: atom-syntax Subject: XML Digital Signatures in Atom feeds and entries I'm currently looking for other Atom implementations that support the option to digitally sign feeds and entries. Apache Abdera supports digital signatures and encryption and I'd like to do some interop testing against other impls. - James
Re: atom license extension (Re: [cc-tab] *important* heads up)
Hello Thomas, Thank you for taking the time to review the draft. I have cc'd this response to the atom-syntax list so that others in the Atom community can comment. Comments below. Thomas Roessler wrote: Hi Mike, James, pleased to meet you. I'm adding Wendy Seltzer to the CC list, who (I think) might have some points to add from a legal perspective. Here's the quick review that I did earlier today: - What's the relationship between licensing information contained in a license-type link and licensing information contained in an atom:rights element? (For the definition of atom:rights, see section 4.2.10 of RFC 4287.) The example under 2.1 in the I-D suggests that the atom:rights is expected to reflect the license that is identified in the link element. However, there seems to be no machine-readable way to express that connection. Also, there can be multiple license links, but only one rights element. This is the third time I've been asked this. I guess I really do need to add a clear statement about the relationship in the spec. With enough thumps on the head I usually come around ;-) The relationship is relatively simple. The atom:rights element is always a human-readable statement of what rights are held over the feed or entry. It's is the equivalent of saying Copyright (c) James Snell and cannot be relied upon to tell the consumer anything useful about what the consumer can do with the feed or entry. The license link, on the other hand, is specifically intended to provide a reference to the license applied to the feed/entry; that is, what kinds of things others are allowed do with the feed/entry. - An atom:rights element on a feed sets the default for the atom:rights elements on entries; a license link on a feed, however, is expected to apply to the metadata and NOT to the entries. Why the difference in inheritance rules and semantics? This is something that I've debated back and forth on but the difference comes down to an issue with aggregated feeds. Take, for instance, Sam Ruby's Planet feed (http://planet.intertwingly.net/atom.xml). This feed consists of entries that originated from many different sources, some of which may have license links, some that might not. If Sam decided to put a license link at the feed level, and if license links were inherited, it would mean that Sam's license would be extended over resources he may have no right to license. Obviously, that's wrong. One two possible solution would be for Sam to some how indicate that an entry in his feed did not have a license link, but doing so could cause other problems (such as invalidating any XML digital signatures that may be covering the entry). Also, it's possible that the entry originally came from a feed that did include a license link, but that some intermediary along the way failed to properly carry over the license link into the entry after separating it from the feed. The bottom line is that license inheritance opens too many potentially significant issues. (and yes, these issues apply equally to the atom:rights element). The simple solution, then, is to specify that license links only cover the feed or entry containing the link. - It's probably worth noting that there are jurisdictions in which databases enjoy sui generis legal protection (e.g., the EU). In such jurisdictions, it might be reasonable to have license information that refers to the collection, not just to its metadata. The selection and arrangement of entries in the feed is covered by feeds license. - The following statement: Entry content might include or reference material from other sources. Licenses associated with an entry MUST NOT be assumed to cover such material. Implementations cannot necessarily trust that publishers have the right to license material claimed to be covered by any associated license. Care should be taken when making decisions based on the referenced license. ... takes all of the value out of this scheme. The very point of annotating content (even aggregate content) with a license is that this license be trusted. (I understand this to be, in part, a legal layman's overstatement; I'll leave it to the lawyers to comment. ;) Yes, I don't like this either. But the fact remains that an entries content may include content from other sources that cannot be assumed to be covered by the license associated with the entry. The analogous situation occurs in Open Source Software distributions in which dependencies shipped with a project may have their own licenses that are distinct from the license used for the project code itself. The question really is whether or not this is worth calling out explicitly in the spec. Summary: The relationship to atom:rigts should be cleaned up. The questions above about what precisely a license applies to probably points at a problem in terms of expressivity of the linking scheme
Re: [cc-tab] *important* heads up
Hey Mike, Thanks for taking another look. Comments below. Mike Linksvayer wrote: Hi James, The atom license extension was brought to my attention again. I'm not sure what concerns Thomas Roessler (cc'd) has below (I've also cc'd Lisa Dusseault as she mentioned the extension to me recently and appears to be involved in the process), but upon re-reading the draft I have one. I obviously did not read very carefully in the past and must apologize for that. In any case, the draft says the referenced license only applies to feed or entry metadata, not content. This strikes me as not particularly useful and does not match analogous extentions for RSS 1.0 and RSS 2.0: The difference in semantics is precisely why I'm not using either the RSS 1.0 or RSS 2.0 extensions for this as I see problems with both the former approaches. http://web.resource.org/rss/1.0/modules/cc/ is RDF, so it is as clear as it can be what license annotations apply to, and in the examples they apply to the content at the feed (channel) URL (the feed itself) and the content at individual entry URLs (content of individual posts). It is helpful to take a look at the RSS 1.0 rdf:license definition. From http://web.resource.org/rss/1.0/modules/cc/: !-- start -- This module aims to give metadata regarding the copyright license under which the RSS feed, and the objects it points to, are released under. [snip] cc:license rdf:resource=URI OF LICENSE / cc:license rdf:resource= can be a sub-element of an RSS item, channel or image. The license it refers to is applied to the parent element. As with any RDF elements, an occurance of cc:license within any element implies the copyright of the document contained with the rdf:about attribute of that parent element, and not the document pointed to by the link sub-element. The element contains a single rdf:resource attribute which contains the URI of the license applied. !-- end -- From this description, and the example that is illustrated in specification of the rdf:license module, it is evident to me, at least, that rss 1.0 channels and items are licensed independently from one another and that an item does not inherit the license of the channel, otherwise, you could end up with significant problems if two feeds referenced the same content item with two difference licenses, e.g. rdf:RDF channel rdf:about=http://example.org/feed1; cc:license rdf:resource=http://example.org/license1; / items rdf:Seq rdf:li resource=http://blog.example.com/2006/08/foo; / /rdf:Seq /items /channel item rdf:about=http://blog.example.com/2006/08/foo; ... /item /rdf:RDF rdf:RDF channel rdf:about=http://example.org/feed2; cc:license rdf:resource=http://example.org/license2; / items rdf:Seq rdf:li resource=http://blog.example.com/2006/08/foo; / /rdf:Seq /items /channel item rdf:about=http://blog.example.com/2006/08/foo; ... /item /rdf:RDF Because of RDF's data model and the definition of mod_cc, if licenses are inherited by the items, these two feeds are either making contradictory claims about the licensing of a single resource, neither or which the channel publishers may actually have the right to license, or they are claiming that the resource has been dual-licensed. Unfortunately, neither claim can be substantiated by looking at the item itself. Note that, because of the RDFs data model, the same problem occurs if the items in each of the above channels each contain their own contradictory cc:license links. Further, there is also the problem that the channel element is describing a different resource that the item element. The definition of cc:license says that the license applies to the parent element and therefore the resource being described by the parent element. It is not specified whether or not that license applies to other resources linked to the channel. Also, there is a bug in the spec that, in certain situations causes the spec to contradict itself. Consider the sentence: an occurance of cc:license within any element implies the copyright of the document contained with the rdf:about attribute of that parent element, and not the document pointed to by the link sub-element then look at the example given in the spec itself. item rdf:about=http://c.moreover.com/click/here.pl?r123; titleXML: A Disruptive Technology/title linkhttp://c.moreover.com/click/here.pl?r123/link cc:license rdf:resource=... / /item The link and the rdf:about attribute point to exactly the same resource, making the assertion in the spec self-contradictory. http://backend.userland.com/creativeCommonsRssModule says license annotations apply to the content of the RSS file and content of that item, mirroring the RSS 1.0 use. I do not believe that the RSS 2.0 definition mirrors the RSS 1.0 use. I've already noted the
Re: atom license extension (Re: [cc-tab] *important* heads up)
Hello Wendy, Thanks for the feedback. I've cc'd the atom-syntax list so the rest of the Atom community can comment. Comments below. Wendy Seltzer wrote: Hi all, So my first thoughts upon seeing the draft are to wonder why it's necessary to make assertions about the legal effects of including a license -- especially since some of those assertions seem to obviate the purpose of using a license declaration. While it's helpful to tell people how to indicate, technically, what they mean for a license to attach to, it's not useful to offer guidance on how to interpret the license. Namely: 1.1 It must also be noted that licenses associated with feeds or entries using these mechanisms are advisory and are not, by themselves, legally binding. Nor can a license associated with a feed or entry restrict or forbid access to, redistribution, aggregation, caching and display of those items by third party intermediaries such as search engines and so-called online aggregators. Why can't they be legally binding? They're not self-executing, but licenses outside of feeds aren't either, and likewise may or may not be legally binding depending upon other things than just the form of their expression. To this point I've received exactly the opposite feedback from others (all of whom weren't lawyers, btw, but who have had experience with licensing issues in the past). It is my understanding that the licenses cannot be considered legally binding *by themselves*. That is, precisely as you indicate, they are not self-executing. 2 License link relations appearing within a feed MUST apply to the metadata of the containing feed element only and do not extend over the metadata or content of any contained entries. Why? Why would a feed need a license separate from its content? Lots of the metadata elements would be functional or would give users fair use claims, absent a license. Sam Ruby's planet feed is a prime example. Sam does not own rights over the individual entries that appear within his feed, however, Sam does own the rights over the feed itself, including the selection and arrangement of entries within that feed. I've mentioned before that it's roughly equivalent to distributing dependencies with an open source project. Each of the dependencies have their own license, distinct from the projects license. Entry content might include or reference material from other sources. Licenses associated with an entry MUST NOT be assumed to cover such material. Implementations cannot necessarily trust that publishers have the right to license material claimed to be covered by any associated license. Care should be taken when making decisions based on the referenced license. This seems to be going down a road of legal interpretation that's unnecessary and not necessarily correct. The current CC licenses are offered on a taker beware basis -- the licensor offers the rights he has, and doesn't guarantee a licensee's rights (or even his own) to anything he might have incorporated. That's not the only way to write a license, though. (Even within CC, version 1 had an explicit representation and warranty section that was dropped in v.2.) Implementations should trust the legal representations only as much or as little as they trust any other claim made by the feed. How licenses chain is a matter of individual legal interpretation. Ok, so if I'm interpreting this comment correctly, the recommendation would be to simply remove the paragraph in question? Forgive me (but please clarify!) if I'm misinterpreting some of the draft. Thanks, --Wendy Thanks for taking the time to review, - James
Re: atom license extension (Re: [cc-tab] *important* heads up)
At 04:08 PM 9/5/2006 -0700, James M Snell wrote: Hello Wendy, Thanks for the feedback. I've cc'd the atom-syntax list so the rest of the Atom community can comment. Thanks James, I'm still not clear on what's happening in 1.1. 1.1 It must also be noted that licenses associated with feeds or entries using these mechanisms are advisory and are not, by themselves, legally binding. Nor can a license associated with a feed or entry restrict or forbid access to, redistribution, aggregation, caching and display of those items by third party intermediaries such as search engines and so-called online aggregators. Why can't they be legally binding? They're not self-executing, but licenses outside of feeds aren't either, and likewise may or may not be legally binding depending upon other things than just the form of their expression. To this point I've received exactly the opposite feedback from others (all of whom weren't lawyers, btw, but who have had experience with licensing issues in the past). It is my understanding that the licenses cannot be considered legally binding *by themselves*. That is, precisely as you indicate, they are not self-executing. What I meant by that is that they don't actively restrict non-compliant use, as a technological protection measure does: I can receive a feed and choose to breach its license. They can have legal effect, though: Unless I have some legal excuse such as fair use, I'm then not compliant and possibly infringing copyright. (You still have to come after me for copyright infringement.) Are you trying to say that the license-rel in the feed is merely a notification to those who are curious that this is probably (but we're not certain) the license under which the feed may be used ? That's the way it reads. If so, what's the point? Don't you either want to assert take the feed under this license or not at all or say nothing and make people come to you and ask? I'd recommend dropping this paragraph, as it may give incorrect legal advice. 2 License link relations appearing within a feed MUST apply to the metadata of the containing feed element only and do not extend over the metadata or content of any contained entries. Why? Why would a feed need a license separate from its content? Lots of the metadata elements would be functional or would give users fair use claims, absent a license. Sam Ruby's planet feed is a prime example. Sam does not own rights over the individual entries that appear within his feed, however, Sam does own the rights over the feed itself, including the selection and arrangement of entries within that feed. That seems minimally useful to me (the license, not Sam's feed!), but why prohibit people from licensing their feeds' content too? Or am I just misreading this, and you're saying that depending on where you put the tag, the license's coverage differs? Entry content might include or reference material from other sources. Licenses associated with an entry MUST NOT be assumed to cover such material. Implementations cannot necessarily trust that publishers have the right to license material claimed to be covered by any associated license. Care should be taken when making decisions based on the referenced license. This seems to be going down a road of legal interpretation that's unnecessary and not necessarily correct. The current CC licenses are offered on a taker beware basis -- the licensor offers the rights he has, and doesn't guarantee a licensee's rights (or even his own) to anything he might have incorporated. That's not the only way to write a license, though. (Even within CC, version 1 had an explicit representation and warranty section that was dropped in v.2.) Implementations should trust the legal representations only as much or as little as they trust any other claim made by the feed. How licenses chain is a matter of individual legal interpretation. Ok, so if I'm interpreting this comment correctly, the recommendation would be to simply remove the paragraph in question? Yes. Thanks, --Wendy -- Wendy Seltzer -- [EMAIL PROTECTED] Visiting Assistant Professor of Law, Brooklyn Law School Fellow, Berkman Center for Internet Society http://cyber.law.harvard.edu/seltzer.html Chilling Effects: http://www.chillingeffects.org
Re: atom license extension (Re: [cc-tab] *important* heads up)
Comments below. Wendy Seltzer wrote: [snip] Thanks James, I'm still not clear on what's happening in 1.1. [snip] To this point I've received exactly the opposite feedback from others (all of whom weren't lawyers, btw, but who have had experience with licensing issues in the past). It is my understanding that the licenses cannot be considered legally binding *by themselves*. That is, precisely as you indicate, they are not self-executing. What I meant by that is that they don't actively restrict non-compliant use, as a technological protection measure does: I can receive a feed and choose to breach its license. They can have legal effect, though: Unless I have some legal excuse such as fair use, I'm then not compliant and possibly infringing copyright. (You still have to come after me for copyright infringement.) Are you trying to say that the license-rel in the feed is merely a notification to those who are curious that this is probably (but we're not certain) the license under which the feed may be used ? That's the way it reads. If so, what's the point? Don't you either want to assert take the feed under this license or not at all or say nothing and make people come to you and ask? What I'm saying is that feed consumers have no guarantee as to who added the license link to the feed/entry and whether whoever did had the legal right to do so. Nor is there any guarantee that license links within a feed or entry have not been inappropriately modified. Feed publishers can digitally sign Atom feeds and entries to provide some non-repudiation protection, but doing so is optional and is not a guaranteed solution. I'd recommend dropping this paragraph, as it may give incorrect legal advice. Ok. 2 License link relations appearing within a feed MUST apply to the metadata of the containing feed element only and do not extend over the metadata or content of any contained entries. Why? Why would a feed need a license separate from its content? Lots of the metadata elements would be functional or would give users fair use claims, absent a license. Sam Ruby's planet feed is a prime example. Sam does not own rights over the individual entries that appear within his feed, however, Sam does own the rights over the feed itself, including the selection and arrangement of entries within that feed. That seems minimally useful to me (the license, not Sam's feed!), but why prohibit people from licensing their feeds' content too? Or am I just misreading this, and you're saying that depending on where you put the tag, the license's coverage differs? It's the latter. The license's coverage differs depending on where it appears. [snip] - James
Re: atom liense extension (was Re: [cc-tab] *important* heads up)
Mike Linksvayer wrote: On Tue, 2006-09-05 at 15:53 -0700, James M Snell wrote: Mike Linksvayer wrote: In any case, the draft says the referenced license only applies to feed or entry metadata, not content. This strikes me as not particularly useful and does not match analogous extentions for RSS 1.0 and RSS 2.0: The difference in semantics is precisely why I'm not using either the RSS 1.0 or RSS 2.0 extensions for this as I see problems with both the former approaches. I understand having problems with RSS 1.0 and RSS 2.0 approaches but I don't see an inherent and important difference in semantics, particularly between Atom 1.0 and RSS 2.0. Of course my vision is probably foggy. :) The difference boils down to one very simple point: contained resources do not necessarily inherit the license of the container. The RSS 1.0 and RSS 2.0 modules both assume that the rights holder of the channel also holds rights over all of the contained items, which works fine when I'm publishing my own blogs entries in my own feed, but breaks down when I'm republishing entries from multiple sources. [snip] (I'm still stewing over the bit of comments that I snipped out of this :-) ...) I agree that assuming entries inherit licenses specified at a feed level is problematic. My concern, at the feed and entry level, is that the atom license extension draft says that a link relation can (only) be used to associate a license with feed or entry metadata, rather than content. Unlike other children of feed and entry the license extension is not metadata for the feed or entry but metametadata for the feed or entry metadata, which strikes me as not particularly useful and contrary to both RSS 1.0 and RSS 2.0 modules, whatever differences exist between those. My apologies if I haven't been clear on this. If you look again at section 1.3, you should find the following: For entry elements, metadata refers to the values and attributes of the author, category, content, contributor, id, link, published, rights, source, summary, title, and updated elements, as well as all extension elements appearing as children of the entry element and all elements appearing as children of the author and contributor elements. Note that the value and attributes of the content, summary, title, etc elements are all included in entry metadata. What isn't covered are any linked resources. So any content actually appearing within the entry is covered by the entry license. (Note that paragaph 4 of section two will be removed in the next iteration per Wendy's suggestion) - James
Re: atom liense extension (was Re: [cc-tab] *important* heads up)
James M Snell wrote: Mike Linksvayer wrote: On Tue, 2006-09-05 at 15:53 -0700, James M Snell wrote: Mike Linksvayer wrote: In any case, the draft says the referenced license only applies to feed or entry metadata, not content. This strikes me as not particularly useful and does not match analogous extentions for RSS 1.0 and RSS 2.0: The difference in semantics is precisely why I'm not using either the RSS 1.0 or RSS 2.0 extensions for this as I see problems with both the former approaches. I understand having problems with RSS 1.0 and RSS 2.0 approaches but I don't see an inherent and important difference in semantics, particularly between Atom 1.0 and RSS 2.0. Of course my vision is probably foggy. :) The difference boils down to one very simple point: contained resources do not necessarily inherit the license of the container. The RSS 1.0 and RSS 2.0 modules both assume that the rights holder of the channel also holds rights over all of the contained items, which works fine when I'm publishing my own blogs entries in my own feed, but breaks down when I'm republishing entries from multiple sources. Here's my rationale: Atom has explicit support in the core RFC 4287 syntax for 'synthetic' feeds containing entries from multiple sources produced by multiple authors with different copyrights. RSS 2.0 doesn't have this core support. So in the case of Atom, the issue is a bit more urgent. So tackling the Atom case first makes sense to me. (Aside: Is there any reason why an Atom extension couldn't also be used as an RSS 2.0 extension too? In this case, there would be a valid reason to add to the already crowded space of license extensions: Because it lets you specify the feed license terms separately from the individual entry license terms, whereas the other RSS licensing schemes don't.) [snip] (I'm still stewing over the bit of comments that I snipped out of this :-) ...) I agree that assuming entries inherit licenses specified at a feed level is problematic. My concern, at the feed and entry level, is that the atom license extension draft says that a link relation can (only) be used to associate a license with feed or entry metadata, rather than content. Unlike other children of feed and entry the license extension is not metadata for the feed or entry but metametadata for the feed or entry metadata, which strikes me as not particularly useful and contrary to both RSS 1.0 and RSS 2.0 modules, whatever differences exist between those. My apologies if I haven't been clear on this. If you look again at section 1.3, you should find the following: For entry elements, "metadata" refers to the values and attributes of the author, category, content, contributor, id, link, published, rights, source, summary, title, and updated elements, as well as all extension elements appearing as children of the entry element and all elements appearing as children of the author and contributor elements. Note that the value and attributes of the content, summary, title, etc elements are all included in entry "metadata". What isn't covered are any linked resources. So any content actually appearing within the entry is covered by the entry license. (Is it just me, or is there too much overloading of "metadata" here?) Also, does this mean that an entry license would apply to this content: content type="image/gif"TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG/content but not to the same content communicated through an indirect link? content type="image/gif" src="" class="moz-txt-link-rfc2396E" href="http://example.org/catpicture001.gif">"http://example.org/catpicture001.gif"/ (I'm deliberately picking a GIF picture as I believe there's no good solution for embedding license metadata inside GIFs. ) -John Panzer
