Security Extension

Consensus: Encryption should be deferred.

Signatures moved to Identity

[KennethLeFebvre] How about "other" aspects of security, such as ACLs? I am currently working on a new feature in my own blogging software to allow me to control the visibility of a post based on the user (through either authentication or IP address), so that the world sees "most" posts, some people see all posts and some people don't see some posts. This can be implemented similarly to allowing users to filter on category, but it is something that is controlled by the publisher rather than the consumer.

[KenMacLeod] Great idea! I would think that would be managed well in a Security or ACL extension, do you see any issues with the core that would indicate that'd be a problem?

[ZhangYining RefactorOk] No problem so far, but a standard and *extensible* WellFormedEntry format for responses indicating authentication/authorization success/failure is needed, instead of aggregator/reader getting an HTTP403 or 500.

Encryption Discussion

Interesting. If an entry is encrypted it can be the equivalent of a private email. Only the recipient would know it was posted. (He would haave a personal feed.) And only the recipient could open it. (With his private key.) In practice (e.g. in PGP) the message is encrypted to both the sender and recipient. So the sender could also decrypt for reference from the public entry.

[JamesSnell] Encrypting entries could be a good solution to providing fee-based RSS feeds. Purchase a license for the feed, get a key that can be used to decrypt the content. It would also be useful for corporate logs containing sensitive confidential material being shared over the internet with business partners or employees.

Hmm. What are the tradeoffs between encrypting individual entries and using database-type permissions for access? The former is a property of the entry (the scope of this dicussion). The latter is a property of the global virtual (but mostly read-only) database of entries.

[GregReinacker] of the goals of this whole thing, as I recall, was to keep things simple for the consumer. PK-encrypted feeds certainly aren't easy today. I'm thinking maybe we punt on this issue for now, and leave authentication and encryption up to the transport? In real life, this will be HTTP for most feeds in the near future...

[MarkNottingham] Agreed - encrypting them won't do much good, because they'll still be available as plaintext to someone with the key, so they'll be redistributed; in this respect, SSL and HTTP authentication would provide equivalent security (the only advantages of content-based encryption would be the ability to persist the encrypted form, and to selectively encrypt the entries). What's wanted here is DRM.

[JoeMadia] +1 on punting encryption for now. However, if a concept of Identity can be agreed upon then I think that digital signatures for items could be useful.

[JoshJacobs RefactorOk] I'm not sure if this is the right place for this comment, but I'd like to see consideration given to reader authentication in subscriptions. This could support Tim Bray's comments about subscribing to financial information, or simply allow personalized pages like myYahoo to be subscribed to. If this is out of scope because Echo is solely focused on providing access to public information I apologize. A personal note from a corporate blogging standpoint, I wouldlike to be able to use public blogging services like Manila or TypePad (so i don't have to deploy servers behind my firewall) but control access to the blog. I see this as another example where aggregators would need to be able to be able to supply credentials to the blog server in order to access the feed.

[JonathanSmith RefactorOk] DannyAyers is tracking RssAndAuthentication.

[WWW]Signing comments by SimonWillison

CategoryModel, CategoryArchitecture