Re: [OAUTH-WG] Flat Token JSON representations and generic JSON providers

On 11/05/12 15:44, Axel.Nennker@telekom.de wrote:
> Oauth core does not care about the access token format.
> OpenID connect has an additional (access)token called id_token and that has a specific format.
> Oauth core does not specify access token formats and expects clients to not to introspect them. AS and RS must have common understanding of the token format.
>
Sure, however I'm not seeing what is wrong with a client attempting to 
keep an access token in some sort of structured storage which can 
accommodate the representations for the different token types.
I think it can be useful for a client to know which access token 
property is a 'key' property and which is an optional one, etc, which is 
easy enough to do with the current representations, but as I said, this 
requires the use of the specialized readers..

Not a bit issue anyway
Cheers, Sergey


> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Sergey Beryozkin
> Sent: Friday, May 11, 2012 4:16 PM
> To:<oauth@ietf.org>
> Subject: [OAUTH-WG] Flat Token JSON representations and generic JSON providers
>
> Hi
>
> AccessToken representations are flat. For example, the token representation may have a token id, type, plus few additional parameters, all being the siblings.
>
> This requires using the specialized JSON providers in case when generic structured token or error representations are used. For example, given the following in Java:
> public class AccessToken {
>     String key;
>     String type;
>     Map<String, String>  additionalProperties; }
>
> it is difficult to use the generic JSON providers to correctly read a sequence of name/value pairs into an instance of AccessToken.
>
> It is not the major issue but I wonder would it be feasible to consider introducing a simple container element for all the optional properties which may be available in a given access token representation ? Probably too late to consider but I'm sending the message just in case anyway
>
>
> Cheers, Sergey
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth