David, are you saying the optional parameter should be a separate spec, or that #3 and #4 are the same thing? (I disagree with both L)
I see a new, standard token and specifying the token format are orthogonal. The PR may accept multiple proprietary token types. if we have the parameter in the spec, then clients know to pass it along if they see it. -- Dick On Fri, Jun 4, 2010 at 10:45 AM, John Kemp <j...@jkemp.net> wrote: > 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) > > - johnk > > > > > > > On Fri, Jun 4, 2010 at 9:58 AM, George Fletcher <gffle...@aol.com> > 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 > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
