Hi all, as discussed yesterday on IRC, it seems that the OAuth layer of CouchDB only covers the authentication mechanisms of OAuth, but not the authorization mechanisms (if I understood correctly, tell me if I'm wrong). However, the authorization layer is IMHO the most interesting part of OAuth:
http://tools.ietf.org/html/draft-ietf-oauth-v2-18 : Abstract The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. But, as it's closely related to read access limitations (in time and scope), it doesn't fit well in the all-or-nothing ready access policy for a given database in CouchDB. After discussion, it seems that the proper way to do this with CouchDB is to set a DB per user and per permission. Following the example given in the OAuth RFC, where a user wants to grant access to his/her pictures (and only his/her pictures) to a printing shop for a limited time (time to print), it seems that in CouchDB we would need to set up a DB for the user's private data, and a for the the user's pictures (and for the user's bookmarks, and so on for each right's scope). Then we just need to grant or not read access to this or that DB, regarding the credentials of the third party request, but I don't know how to do this with the current ACL policy wich doesn't seems to match the OAuth's token system (the third party request must show a token, but how/where can I check it? How/where can I handle token's expiration time?). Do you think there is anyway to handle this? Or should I fallback to the "smart proxy" solution? Thanks, Regards, Camille. -- The Good, the Bad and the Ugly under Creative Commons! https://yooook.net/r/lp1
