Few responses on this topic: On May 25, 2010, at 7:08 AM, Manger, James H wrote:
> 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. It's a pretty reasonable issue to raise. Extra complexity when not needed in the common case bogs down the spec. >> 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. A URL of a=1&b=2 is naturally a hashtable. There is no natural way to represent arrays in URL parameters. PHP even converts normal arrays into hashtables. Generally it's much easier for developers to deal with simple key/value pairs. > I have some reluctance in supporting multiple tokens as, say, 50% of early > services might not use them initially. Where do you get this stat from? Facebook has no need for multiple tokens, and generally > 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). As Justin suggested, I think it would be a good exercise to figure out how your requirements could be represented as a backwards-compatible extension instead of increasing complexity of the core spec. I'm confident that this would not require a rewrite of the protocol. _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
