> But the service will recognize the same fixed set of scopes, > regardless of how many reliers are accessing it. That's what I > mean by "orthogonal" in this context.
Ah, okay, I get were you're coming from now. I believe this means it's not possible to access user's collections to determine what are the set of scopes you want. Because we are crafting a "generic" storage, *we cannot know upfront what the collections defined by the users will be*, and so if I understand correctly, it will not be possible to use present the users with these scopes so she can chose? > In a previous email, there was suggestion that e.g. the payments > relier could have a special "paymentsapp" scope that nobody else > is allowed to request. This was the part that didn't seem right to > me. The scopes should be "things that someone can do" and the > reliers are "entities who can do things" and they should be two > independent sets. Gotcha. We'll get this done with permissions on the storage service, and not rely on scopes for this. Whatever the scopes say, and should be ANDed with the permissions on the accessed objects. > I can imagine us adding similar restrictions on a case-by-case > basis, e.g. you might have to go through some sort of verification > process before we allow your app to request the "payments" scope. Neat, that's exactly the kind of things I was thinking about. > But I assume that you signing up as a twitter relier didn't create > a new privileged "alexis" scope that only your app can access, and > you as a relier didn't have the opportunity to create new scopes. Of course, you assume right (and I understand even better why you were having this foreword about OAuth doing authz and not authn ;)) >>> 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). > > This bit I don't understand sorry - what effect does a new > client_id coming online have on the scopes offered by the storage > service? ?? > Thanks Alexis, I feel like I understand things a lot better now! Neat, thanks for the useful answers to newcomers questions ;) > All of the above seems to be about Bob delegating authority that > he already has. For example, Bob has the ability to > "contacts:read" so he is able to pass that authority over to a > third party via the OAuth dance. Yes. > How do you see this working for payments, where we want to grant > the payments backend app a capability that Bob does not have? > (Namely, the ability to write new payment receipts into the > store). This is where we're thinking to not rely on OAuth scopes. The payments application will register a new receipt in the store, using its (service) authentication. For instance, a receipt for Bob concrete bricks subscriptions. When the new receipt will be added, a permission will be set for Bob to read this record. When a User-Agent will request for this information, he will be authenticated via its bearer token (yes, that's using OAuth for authentication) and it will be authorized at the storage level. > Do we create a scope like "payments:write" that Bob himself is not > allowed to have, but that the payment app can grant to itself via > some backend token dance? In some sense, that's what we would like to have. But as you said, if we look at the storage as something generic, payments is just one generic thing it can do, and as such it would mean the service will not "recognize the same fixed set of scopes, regardless of how many reliers are accessing it", since the storage server allows to create new ones on the fly. At least, I think we're at the heart of the problem ;) -- Alexis. GPG Key — 0x95E3C667D1CFA3CE
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
