Torsten, On Jun 4, 2010, at 2:31 PM, Torsten Lodderstedt wrote:
> > Am 04.06.2010 19:45, schrieb John Kemp: >> On Jun 4, 2010, at 1:35 PM, David Recordon wrote: >> >> >>> #4 should happen as part of #3. >>> >> How would ALL OAuth 2.0+ clients know to pass along the format if it is >> there? >> >> I fail to see the problem with specifying an optional token format parameter >> in the main spec. and giving it a default value, and semantics of "opaque" >> for when it isn't present (ie. the current case). That explicitly allows >> other specifications to use the attribute, and is then good for future >> interoperability (and also future backwards-compatibility) >> >> > > there is another point: such a parameter could be used to let the > authorization server indicate the format of the access token to the resource > server. This will help deployments with more than one token format in use. > For example, we use SAML and another proprietary format. Without such a > parameter, the resource server has to somehow (magically) find out the format > of the incomming token. Yes, that's a good additional point. > > From my point of view, #4 should happen now independent of #3. Agreed. - johnk > > regards, > Torsten. >> - johnk >> >> >>> >>> On Fri, Jun 4, 2010 at 9:58 AM, George Fletcher<[email protected]> wrote: >>> Could I conclude then that "we" are all in "agreement"? :) >>> >>> 1. OAuth 2.0 should not require a structured token (i.e. don't break >>> existing use cases) >>> 2. OAuth 2.0 should not prohibit resource owners supporting multiple >>> Authentication Servers >>> 3. OAuth 2.0 should allow for structured tokens via a separate spec >>> 4. OAuth 2.0 should consider specifying an additional, optional parameter >>> that is opaque to the client but identifies the "token format" >>> >>> Thanks, >>> George >>> >>> >>> On 6/4/10 12:45 PM, Luke Shepard wrote: >>> On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote: >>> >>> >>> There is more to the web than the social web Luke, and supporting multiple >>> AS has been a design goal of WRAP and OAuth 2.0 and is being implemented. >>> >>> Whoa, I didn't say there wasn't. I agree that supporting multiple >>> authorization servers is a reasonable design goal and there are some people >>> who are making that work. >>> >>> I was just pointing that that a common case, today, is to have a single >>> authorization server for a given resource - I mentioned several examples of >>> services that work this way now. OAuth 2.0 needs to support that use case >>> in a clean way.= >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
