Justin, > I don't want to always have to grab "token[0]" from the response where before > i just grabbed "token".
Surely token[0] vs token is too trivial to be an issue. > Also, this approach ties us to a hierarchical data representation format like > JSON instead of being able to use anything that can hand us simple key-value > pairs. Hashtables/dictionaries/associative-arrays are very easy to manipulate > and understand in many languages. An array is even simpler than a hashtable. An array of hashtables is still very easy to manipulate in any language. Info on any particular token can still be a hashtable. > If we can do this in a way that doesn't create overhead for the single-token > case and > if we can figure out a way to serialize it in a flat way as well, then I'm > all for it; We can certainly figure out a way to serialise it in a flat way -- but it will look messy. OpenID manages to serialise in a flat way all sorts of structured info, even from different namespaces. Its just that few will tolerate such a mess today given the wide availability of a standard such as JSON that provides the basic structure without mess. [Actually a good argument for JSON is we can have the more important discussions on new functionality (such as multiple tokens), on message flows, on semantics etc without constantly being concerned about serialisation, arguing about how to squeeze the logical messages into a single flat ASCII-subset hashtable.] > but I don't think we should add this much complexity just to save a few round > trips. I am in favor of Dick's proposal(s) for re-scoping and revoking > existing tokens using the refresh token as credential. This would allow > clients to grab a refresh token then make one more call each to grab whatever > access tokens they wanted to. If you have multiple calls to get multiple tokens you still need client apps to be capable of managing multiple tokens. At that point you have already accepted the complexity. Whether the tokens are collected in multiple calls or parsed from one response is not the complex part. I think the real argument is whether multiple tokens are a choice by the client app or a requirement by the server. If it is a choice by each client app, then some client apps could be a bit simpler by choosing to only to use a single token. On the other hand, if a server is allowed to enforce multiple tokens (for different content servers / scopes; for HTTP and HTTPS; for user-agents and web-servers etc) then there is no avoiding support for multiple tokens in generic OAuth2 client apps (and OAuth libraries in particular). I have some reluctance in supporting multiple tokens as, say, 50% of early services might not use them initially. However there are enough real use cases that I do think OAuth2 needs to support multiple tokens. If, in a few years, 99% of services make do with a single token then no one will bother coding the extra complexity and code will trivially skip the extraneous "[" and "]" around the token info (ie no harm done for service-specific apps; limited hassle for generic apps). More likely is that if we don't support multiple tokens a bunch of use cases can't be supported and an incompatible OAuth3 will be needed next year (major harm for everyone). -- James Manger _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
