Re: [OAUTH-WG] Partially standardized format for access tokens?

+1

FYI, OpenID Artifact Binding Draft (which is OpenID on OAuth) defined a
"server_id" variable to tell from where it was issued. It can be used as
token_origin,
but not limited to it. It also can show where the response came from (in the
record).

=nat

On Sat, Jun 5, 2010 at 1:58 AM, George Fletcher <gffletch@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
>

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en