It seems that these concepts should be given more of a first class status than just deduced from the populated fields. Maybe it's not a big issue, but I can imagine developers forgetting a field, and getting back different data than they expected. Also, it might be worth having this in a big matrix with the meaning of the OAuth parameters (which get translated into a SecurityToken by the AuthFilter), since there is so much overlap in domain.
Bob On Thu, Aug 14, 2008 at 2:56 PM, Louis Ryan <[EMAIL PROTECTED]> wrote: > 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 >
