#1 #2 feels like overengineering, and we're going to end up with things that spit back stuff that aren't token attributes anyway that will want to put them at the top level.
Also, no need to require a more complex structure. I tried to make it so that the XML encoding can handle more complex things like lists and sub-objects, but even so I'd rather keep the basic specification (and recommendations for extensions) as flat as possible. -- Justin On Thu, 2010-12-02 at 16:04 -0500, Eran Hammer-Lahav wrote: > I'm defining a new token type: MAC based on my previous HTTP Token > authentication draft (which in turn was based on 1.0a HMAC-SHA1). This is > being drafted and implemented in my current project (in node.js). I will have > a draft to share shortly (I do not plan to make this a WG item, but will not > object if the group wants to). > > When issuing a token, the authorization server needs to provide two > additional attributes: > > - mac algorithm (hmac-sha1 and hmac-sha256 will be defined) > - secret > > I have two options; extend the token response by registering: > > 1. Type specific parameters: 'mac_algorithm' and 'token_secret' > 2. Generic parameter: 'attributes' with some form of key-value pairs > > I prefer #1 because it is much simpler. However, #2 is cleaner and better if > we end up with a lot of token types. > > So I'm going with #1 but open to other suggestions and feedback. > > EHL > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
