Torsten, > Scopes (~permissions) should be defined allong with the corresponding API.
But they aren't. Lots of "APIs" -- particularly the most important/standard ones, like AtomPub, HTML itself, IMAP (?)... are already defined, or are defined separately from any permissions that one service chooses for their implementation. Permissions can be coarse grained (eg have access / don't have access), or fine grained (eg can read green items on Fridays), or anywhere in between. If every client app always needs service-specific knowledge about how permission are arranged I don't think we can get much interop. > Depending on the IMAP feature set you want to use there could be plenty of > scopes, ranging from "read users INBOX" to sharing scenarios, where users have access to other users IMAP folders. [I am not sure that IMAP is a great example as I assume it isn't an HTTP protocol, but ignoring that] I hope that if an IMAP service says "I support OAuth2", and a client app says "I understand IMAP and OAuth2" then they can interoperate with minimal config. The app may need an app-id/secret, it may need an URI to start at (perhaps even a complicated one), but I hope it doesn't also need a table of service-specific permission labels against every possible IMAP operation. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
