Hi, Id like to propose that we define more tightly the semantics of the fields on SecurityToken's and what consumers of its information should infer. The security token basically carries viewer-id, owner-id and app-id as its three fundamental pieces of data.
I'd like to propose the following semantics for permutations of those fields, some of which is just re-hashing what we already do *1. (app-id=<not set>, viewer-id=<not set>, owner-id=<not set>)* - This is the case of anonymous access to the API. This would only be allowed to access public resources. *2. (app-id=<some id>, viewer-id=<some id>, owner-id=<some-id>)* - This is the common gadget rendering case where an application is allowed to make API calls acting-on-behalf of the viewer who is the authenticated principal. This token is typically quite a restrictive, for example this token may not allow modification of the owner-id's AppData. *3. (app-id=<some id>, viewer-id=<not set>, owner-id=<not set>) *- The is the case of a trusted third-party which can assert ownership of the specified application. This token would typically grant greater access than the prior one, e.g it may grant access to update the AppData for any user that has granted permissions to the specified application. *4. (app-id=<not set>, viewer-id=<some id>, owner-id=<not set>)* - The is the case of a call to the API authenticated as the viewer. This would be common for desktop applications that ask users for user/pass to authenticate calls on the API. This token may grant greater access to the users profile information than any of the prior ones. It would make a certain amount of sense to codify each of these cases. Currently 1 is defined as 'isAnonymous' in our interfaces. Potential names for 2-4 are 2. isApplictionOnBehalfOfUser 3. isApplication 4. isAuthenticatedUser Thoughts? -Louis
