Okay, After having put some more thoughts in, it seems that we need to use OAuth2.0 scopes, but not as a traditional way to define permissions for the users.
As Ryan said, what we need is an *extra* permission layer on top of what FxA scopes can propose. Since this is not easy to understand at first sight, let me try to describe it further. Taking back the example Rémy took in an earlier thread: Consider two collections for a given user, Bob: "Tasks" and "Contacts". And then two applications, which need different accesses rights: - "Address Book", which need `read+write` permission on the "Contacts" collection; - "Todo List", which needs `read` permission on "Contacts" and `read+write` permission on "Tasks". All this data belongs to Bob, but he wants to have different applications access his data with different rights. That's where scopes come into play. Even if Bob has all read+write rights on both collections, he wants to give the apps only a subset of these. In our example, he would give "address book" the "tasks:read+write" and "contacs:read" scopes, even if he, as a user has access to everything. It might not be easy to get when looking at user data (where the user has all the rights) but there are indeed two levels of authorization here: Bob should have access AND the application should have access. With that in mind, let's take back Ryan previous remarks: > This seems to go against the grain of OAuth, where scopes and > reliers are orthogonal concerns. I think of client_id as "who you > are" and the scopes as "what you can do" and it doesn't seem like a > good idea to conflate them. Here, scopes and reliers aren't really orhogonal concerns, of course, since the scopes are defined for the reliers. The client_id defines who "the app" is, and I would expect to have some way to say "this app should only access these scopes". I remember seing this with the Twitter API when registering an application, where they were asking me which scopes I should be able to ask. > Note that tokens are tied to the client_id that generated them. > Given a token, you can always tell which client_id "owns" it. That would work for a non-generic storage, but here, for a generic storage, it's kind of tricky since we don't know what the clients ids will be and what they should do at the begining (and new ones should be able to be created). I believe what I want is a way to protect our users against themselves, e.g. them clicking "yes, I want to grant this scope for this app" even if they don't understand the implications. Maybe we should do that and we should let the user make informed choices, but I'm pretty sure they'll do the wrong thing in a good portion of cases. Or, and that's something we should think about carefully, these scopes should be shown to the user in a clever way, so they exactly know what they do and the can make an informed decision. > Let's dive deeper into the requirements driving this question, I > suspect we can come up with something cleaner. What do you want to > achieve by restricting scopes in this way? I believe I formulated and answer to that already, if not, please tell me and I'll be happy to do it differently! Thanks, -- Alexis. GPG Key — 0x95E3C667D1CFA3CE
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
