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

From: Andrew Arnott <[email-masked]>
Date: Fri, 4 Jun 2010 06:37:43 -0700

Having just implemented OAuth 2.0 web server flow, it was great to be able
to issue an "opaque" access token to the client.  This access token is in an
encrypted format that only the resource server understands.  I feel pretty
good about this approach as it lends to high security and tokens that only
the client needs to store (or not at all).

But I'm wondering about the resource server that trusts multiple auth
servers, which each have their own access token format.  Without even a
standardized way for an access token to express what format it is in, a
resource server may have to just try decoding the token each known way until
one "works".

Proposal: perhaps the access token can be *mostly* opaque, but not quite.
For instance:
The access token is in the format:  *format=URI&opaquevalue*
Where URI is an arbitrary URI assigned by the auth server to assist the
resource server in interpreting the *opaquevalue* part of the token.

Feedback?

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

---

From: Luke Shepard <[email-masked]>
Date: Fri, 4 Jun 2010 06:53:26 -0700

Having a single resource server that works with multiple independent auth servers is not in scope for OAuth. That said, there's nothing to stop multiple servers to agree amongst themselves to have a standardized format for access token- and if necessary, to write that agreement as a separate spec (perhaps an extension).

In particular, I wouldn't like your proposal because of the use of equals and ampersand, both of which would need to be URL encoded so developers couldn't copy/paste the token as easily. For Facebook, it's important that the access tokens are as short as possible; other sites may have different requirements.

On Jun 4, 2010, at 6:37 AM, Andrew Arnott wrote:

Having just implemented OAuth 2.0 web server flow, it was great to be able to issue an "opaque" access token to the client.  This access token is in an encrypted format that only the resource server understands.  I feel pretty good about this approach as it lends to high security and tokens that only the client needs to store (or not at all).

But I'm wondering about the resource server that trusts multiple auth servers, which each have their own access token format.  Without even a standardized way for an access token to express what format it is in, a resource server may have to just try decoding the token each known way until one "works".

Proposal: perhaps the access token can be mostly opaque, but not quite.  For instance:
The access token is in the format:  format=URI&opaquevalue
Where URI is an arbitrary URI assigned by the auth server to assist the resource server in interpreting the opaquevalue part of the token.

Feedback?

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
<ATT00001..txt>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 04 Jun 2010 16:05:53 +0200

+1, but why only partially?

I would like to add another use case for a standardized token format. 
Suppose a software vendor wants to built and sell a standard software 
component (service), e.g. an address book service, which is secured 
using OAuth2.  Having a standardized token format would make the 
integration of that "standard software" within customer deployments 
easier. Indeed, the customers authorization server must "speak" that 
token format.

SAML would be a natural candidate from my point of view, a more compact 
variant (based on JSON?) would be fine.

I think, a standard token format should be covered in a separate 
specification.

regards,
Torsten.

Am 04.06.2010 15:37, schrieb Andrew Arnott:
> Having just implemented OAuth 2.0 web server flow, it was great to be 
> able to issue an "opaque" access token to the client.  This access 
> token is in an encrypted format that only the resource server 
> understands.  I feel pretty good about this approach as it lends to 
> high security and tokens that only the client needs to store (or not 
> at all).
>
> servers, which each have their own access token format.  Without even 
> a standardized way for an access token to express what format it is 
> in, a resource server may have to just try decoding the token each 
> known way until one "works".
>
> Proposal: perhaps the access token can be /mostly/ opaque, but not 
> quite.  For instance:
> The access token is in the format: /format=URI&opaquevalue/
> Where URI is an arbitrary URI assigned by the auth server to assist 
> the resource server in interpreting the /opaquevalue/ part of the token.
>
> Feedback?
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the 
> death your right to say it." - S. G. Tallentyre
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: George Fletcher <[email-masked]>
Date: Fri, 04 Jun 2010 10:06:22 -0400

+1 to some standardization to the token

The URI would also allow for discovery and the ability for the provider 
to define an endpoint in the XRD for the URI that allows "dumb mode" 
token validation. This way, even if the resource owner doesn't know how 
to "crack" the token locally, they could ask the provider to do it for them.

Thanks,
George

---

From: George Fletcher <[email-masked]>
Date: Fri, 04 Jun 2010 10:19:24 -0400

On 6/4/10 9:53 AM, Luke Shepard wrote:
> Having a single resource server that works with multiple independent 
> auth servers is not in scope for OAuth. That said, there's nothing to 
> stop multiple servers to agree amongst themselves to have a 
> standardized format for access token- and if necessary, to write that 
> agreement as a separate spec (perhaps an extension).
-1

limiting OAuth to a single Authorization Server (AS) and it's associated 
SPs (resource owners) significantly restricts the value of delegation 
across the internet.

On the other hand, if OAuth allows for cross AS token processing, then 
it becomes very easy for me to protect my photo album while not 
requiring that all those I've shared it with to have an account at my 
photo service (as one example; there are many more).

Thanks,
George
>
> In particular, I wouldn't like your proposal because of the use of 
> equals and ampersand, both of which would need to be URL encoded so 
> developers couldn't copy/paste the token as easily. For Facebook, it's 
> important that the access tokens are as short as possible; other sites 
> may have different requirements.
>
> =

---

From: Eve Maler <[email-masked]>
Date: Fri, 4 Jun 2010 07:30:08 -0700

This is exactly the direction UMA is headed (as George knows :-), since we *are* trying to solve for "unmooring" authorization servers and resource servers -- which we call authorization managers and hosts.

The absolute simplest thing to do is hand out tokens that are essentially artifacts that the host must carry over and validate at the AM (I think Dick was calling these "identifiers" but I'm coming to like "artifact"). But by then, in our case, the host and AM have already met in the context of the user who controls the protected resource in question, and in fact the host has gotten an access token to use at the AM's token validation endpoint so it already knows where to go to validate. Thus, the artifact could be an opaque string.

There are other aspects to the host-specific API at the AM that become handy/necessary when you have to build in this kind of dynamic association.  For example, the host needs to tell the AM what resources it's protecting on behalf of this user; we're fleshing out that API now, but for now it's just POSTing a complete JSON structure (wielding its access token to do so). And I believe it's possible to solve some scoping interop this way too, though we're not there yet by a long shot.

Would love to have folks interested in these use cases come on over to the UMA WG and share their thoughts:

http://kantarainitiative.org/confluence/display/uma/Home

	Eve

On 4 Jun 2010, at 7:06 AM, George Fletcher wrote:

> The URI would also allow for discovery and the ability for the provider to define an endpoint in the XRD for the URI that allows "dumb mode" token validation. This way, even if the resource owner doesn't know how to "crack" the token locally, they could ask the provider to do it for them.
> 
> Thanks,
> George
> 

Eve Maler
[email-masked]
http://www.xmlgrrl.com/blog

---

From: Luke Shepard <[email-masked]>
Date: Fri, 4 Jun 2010 08:00:36 -0700

On Jun 4, 2010, at 7:19 AM, George Fletcher wrote:

> limiting OAuth to a single Authorization Server (AS) and it's associated SPs (resource owners) significantly restricts the value of delegation across the internet.
> 

I'm not saying that we need to limit it just to that circumstance, but the single-server scenario is one of the most common use cases for OAuth - for example, Google, Flickr, Facebook, Yahoo, Twitter all generally support tokens that only work on their own services. I've listed one reason why a formalized structure would be bad for Facebook (token size would increase).

We should solve one problem at a time. It's easy to layer structure on top of an opaque blob in a separate spec. The question to ask is, if a provider chose NOT to support whatever standardized token format that came up, would they still be able to use the OAuth 2.0 flows? If the answer is yes, then it belongs in a different spec.

> On the other hand, if OAuth allows for cross AS token processing, then it becomes very easy for me to protect my photo album while not requiring that all those I've shared it with to have an account at my photo service (as one example; there are many more).

There is a lot more that would need to happen to support this outcome than merely standardizing the format of the token.

---

From: John Kemp <[email-masked]>
Date: Fri, 4 Jun 2010 11:21:50 -0400

Hi Luke,

> We should solve one problem at a time. It's easy to layer structure on top of an opaque blob in a separate spec. The question to ask is, if a provider chose NOT to support whatever standardized tok…

I think that even if specific token formats are defined in separate specs. (which I agree with) you would still need to define a standardized optional attribute to carry the format description reference. 

What is wrong with agreeing in OAuth itself to do that much - define an optional attribute called "token_format" which MAY be present, and if so MUST be passed on by the client? If the format attribute is not present, it's value has default semantics of "opaque"? Other specifications may then define additional format values and describe in more details what they mean. 

Regards,

- johnk

---

From: Justin Richer <[email-masked]>
Date: Fri, 4 Jun 2010 11:23:16 -0400

> We should solve one problem at a time. It's easy to layer structure 
> on top of an opaque blob in a separate spec. 

+1 to this. Token structure seems like a nice idea, but it's outside
what should be dictated by the OAuth spec. We want people to be able to
use OAuth to shuttle their existing tokens around, or create hexblobs
that mean nothing to anyone else, or encode 37 fields in a structured
format that's signed with a private key, or whatever else they want to
do, and still have all of that be OAuth. If someone wants to say "we use
OAuth and our tokens are UberTokens so they're compatible with everyone
else", that's fine; but you should be fully able to do OAuth without
adding *any* structure to your tokens whatsoever.

 -- Justin

---

From: Dick Hardt <[email-masked]>
Date: Fri, 4 Jun 2010 08:37:26 -0700

> adding *any* structure to your tokens whatsoever.

Token format has been out of scope of WRAP and OAuth 2.0.

A separate spec defining standard tokens has been discussed.

Luke was commenting on not supporting multiple AS. That *IS* in scope and
was a design objective and *IS* being implemented.

-- DIck

---

From: Dick Hardt <[email-masked]>
Date: Fri, 4 Jun 2010 08:41:39 -0700

On Fri, Jun 4, 2010 at 8:00 AM, Luke Shepard <[email-masked]> wrote:

> auth servers is not in scope for OAuth. That said, there's nothing to stop
> multiple servers to agree amongst themselves to have a standardized format
> for access token- and if necessary, to write that agreement as a separate
> spec (perhaps an extension).
> > -1
> >
> SPs (resource owners) significantly restricts the value of delegation across
> the internet.
> >
>
> I'm not saying that we need to limit it just to that circumstance, but the
> single-server scenario is one of the most common use cases for OAuth - for
> example, Google, Flickr, Facebook, Yahoo, Twitter all generally support
> tokens that only work on their own services. I've listed one reason why a
> formalized structure would be bad for Facebook (token size would increase).
>
> We should solve one problem at a time. It's easy to layer structure on top
> of an opaque blob in a separate spec. The question to ask is, if a provider
> chose NOT to support whatever standardized token format that came up, would
> they still be able to use the OAuth 2.0 flows? If the answer is yes, then it
> belongs in a different spec.

Agree we don't standardize the token. Disagree on supporting multiple AS.

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.

Having an optional parameter that would carry the token type from the AS to
the PR would be useful and has been discussed in the past. Just like the
access token, it could be opaque to the client.

-- Dick

-- Dick

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 04 Jun 2010 09:45:47 -0600

> adding *any* structure to your tokens whatsoever.

Agreed. And in true IETF fashion, I welcome those who care about this
issue to write an Internet-Draft. :)

BTW, it's possible that you might glean some interesting ideas from a
previous attempt to define an open token format (for cookies):

http://tools.ietf.org/html/draft-smith-opentoken-02

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 04 Jun 2010 17:57:30 +0200

+1 for an optional "token_format" attribute/parameter

---

From: Dick Hardt <[email-masked]>
Date: Fri, 4 Jun 2010 09:23:29 -0700

+1 (just in case that was not clear from my other emails :)

---

From: Luke Shepard <[email-masked]>
Date: Fri, 4 Jun 2010 09:45:15 -0700

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.

---

From: George Fletcher <[email-masked]>
Date: Fri, 04 Jun 2010 12:58:26 -0400

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:
> 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.=
>
>

---

From: David Recordon <[email-masked]>
Date: Fri, 4 Jun 2010 10:35:06 -0700

#4 should happen as part of #3.

On Fri, Jun 4, 2010 at 9:58 AM, George Fletcher <[email-masked]> wrote:

> 4. OAuth 2.0 should consider specifying an additional, optional parameter
> that is opaque to the client but identifies the "token format"
>
> Thanks,
> George
>
>
>>> 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.=
>>
>>
>>

---

From: John Kemp <[email-masked]>
Date: Fri, 4 Jun 2010 13:45:57 -0400

> #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

> 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
> 4. OAuth 2.0 should consider specifying an additional, optional parameter that is opaque to the client but identifies the "token format"
> 
> Thanks,
> George
> 
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 04 Jun 2010 20:31:31 +0200

> 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 ca…

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.

 From my point of view, #4 should happen now independent of #3.

regards,
Torsten.
> - johnk
>
>    
>>
>> On Fri, Jun 4, 2010 at 9:58 AM, George Fletcher<[email-masked]>  wrote:

---

From: Dick Hardt <[email-masked]>
Date: Fri, 4 Jun 2010 11:33:14 -0700

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 <[email-masked]> wrote:

> 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
>
> >
> >

---

From: Dick Hardt <[email-masked]>
Date: Fri, 4 Jun 2010 11:35:02 -0700

You earlier stated that multiple AS was out of scope. I am aligned that
using OAuth 2.0 needs to support the widely deployed social web use cases --
if you recall, I drove getting rid of the signature requirement! :)

On Fri, Jun 4, 2010 at 9:45 AM, Luke Shepard <[email-masked]> wrote:

> a clean way.

---

From: Justin Richer <[email-masked]>
Date: Fri, 4 Jun 2010 15:46:40 -0400

1. ++
2. ++
3. ++
4. ++ as a part of 3., otherwise --

 -- justin

---

From: John Kemp <[email-masked]>
Date: Fri, 4 Jun 2010 15:52:38 -0400

Torsten,

On Jun 4, 2010, at 2:31 PM, Torsten Lodderstedt wrote:

> 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

---

From: Luke Shepard <[email-masked]>
Date: Fri, 4 Jun 2010 18:39:35 -0700

I don't see how the extra parameter is required to support multiple auth servers for a resource.

Responses to Dick and Torsten:

On Jun 4, 2010, at 11:33 AM, Dick Hardt wrote:
> if we have the parameter in the spec, then clients know to pass it along if they see it. 

My main objection here is that the extra param requires more code on the client. Even if it's an optional param, the client needs to worry about multiple parameters, and that's annoying.

For example, here's the PHP code needed to make a resource request today (at the end of the web server flow):

  $access_token = oauth_get_access_token($_GET['code']);
  $resource = file_get_contents('https://example.com/resource?oauth_token=' . $access_token);

With this proposal, the client now needs to keep track of two parameters and pass them both:

  list($access_token, $format) = oauth_get_access_token($_GET['code']);
  $resource = file_get_contents('https://example.com/resource?oauth_token=' . $access_token . '&format=' . $format);
 
Why?

> 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…

It's not "magically" - the server just decodes the token and extracts any useful information it's expecting. If it doesn't match the format it expects, then it throws it away. Tokens will undoubtedly encode all sorts of useful stuff that resource servers know how to decode - like format, expiration, scope, whatever. The point is that the structure is undefined *to the client*.

For example, if the format is just encoded in the token, like this:

   format=ubertoken&token=abcdefg

The protected resource request is then:

   https://example.com/resource?oauth_token=format%3Dubertoken%26token%3Dabcdefg

and there's no extra code required on the client. Why is this not sufficient?

---

From: Dick Hardt <[email-masked]>
Date: Fri, 4 Jun 2010 18:58:36 -0700

> I don't see how the extra parameter is required to support multiple auth servers for a resource.

it is needed if there are multiple token types

>  $resource = file_get_contents('https://example.com/resource?oauth_token=' . $access_token . '&format=' . $format);

The client would only need to do that if the AS will issue the parameter. I would expect that libraries would deal with the two parameters. Moving an extra one around does not seem to be hard. 

> It's not "magically" - the server just decodes the token and extracts any useful information it's expecting. If it doesn't match the format it expects, then it throws it away. Tokens will undoubted…

what if there are multiple token formats? that is were the magic comes in. Detecting format can be tricky.

> and there's no extra code required on the client. Why is this not sufficient?

one token could be SAML, another JSON in one format, another in URL encoded name/value pairs.  The PR is having to detect both syntax and semantics.

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 7 Jun 2010 13:14:57 +1000

OAuth2 has a field for AS-to-PR communications via (but opaque to) the client: access_token. Any format indication (like a variety of other details) that an AS wants to convey to the PR via the client app should be *inside* this existing field.

Defining an optional prefix for access_token values to indicate the format would work well.
I suggest a plain text label separated by, say, a "." from the rest of the value. For example:
  access_token=saml.fhHFhgf6575fhgFGrytr
There can be an IANA registry for prefixes if that is helpful.
A service currently supporting a single token format can start its access_token values with "." so at least they will not accidentally clash with any future values that do specify a format.
  access_token=.6786345_JGJSgfjhsgfhj-ss_s
A service that will never need token format interop doesn't need to using any prefix (empty or otherwise), and can use dots however it wants.

P.S. OAuth2 has no explicit statement about allowed chars in an access_token. The <token-id> ABNF in section 5.1 "Authz Request Header" implies 77 ASCII chars are allowed.
I think the spec should explicitly say access_token values can only use the 66 <unreserved> chars. It avoids escaping issues in XML attributes, XML content, JSON, URIs, form bodies, HTTP headers etc. It is safer (less chance of XSS-style bugs); it can easily support arbitrary text or binary formats by using a base64url encoding.

-- 
James Manger

---

From: Andrew Arnott <[email-masked]>
Date: Mon, 7 Jun 2010 08:42:42 -0700

(resending to DL due to apparent DL failure over the weekend... I know Dick
and Luke already received my email because they were individual recipients
as well... I don't know if the DL received their replies or not)...

Great discussion, all.  I am also for an optional parameter that's part of
the main spec, and defining possible structures for the access token in
separate specs.

But *token_format* is not the idea I think.  It's more like *token_origin.
*The scenario I had in mind was that a RS actually accepts access tokens
from two auth servers, both tokens are in the *same* format, but the RS
needs to know which public keys to apply while verifying signatures and
decrypting the token in order to complete it successfully.  Now, an AS
identifier *could* be encoded directly into the access token to help the RS
know, which is fine if everyone was coordinating their design together.  But
if you have two auth servers issues encrypted access tokens in different
formats, it gets *much* harder for the resource server to decide how to
decrypt, verify, and decode the access token.  As the number of auth servers
supported by a RS goes up, the trial-and-error approach gets progressively
worse.

The only way I can see to avoid this is for an OAuth 2.0 specified standard
to exist so that all auth servers provide a way for RS to know "ok, this
access token came from *x*, so I'll decode it this way..."

So to recap, *knowing just the format is insufficient, *since that doesn't
tell you the public keys to use.  Including the public keys in the token
itself will significantly increase the size of the token, and assumes again
that the RS knows how to pull it out in advance of decoding it.
Chicken-and-egg problem.

On Fri, Jun 4, 2010 at 6:58 PM, Dick Hardt <[email-masked]> wrote:

> > My main objection here is that the extra param requires more code on the
> client. Even if it's an optional param, the client needs to worry about
> multiple parameters, and that's annoying.
> >
> >  $resource = file_get_contents('
> https://example.com/resource?oauth_token=' . $access_token);
> >
> >  $resource = file_get_contents('
> https://example.com/resource?oauth_token=' . $access_token . '&format=' .
> $format);
> >
> > Why?
>
> The client would only need to do that if the AS will issue the parameter. I
> would expect that libraries would deal with the two parameters. Moving an
> extra one around does not seem to be hard.
>
>
> >
> 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.
> >
> > It's not "magically" - the server just decodes the token and extracts any
> useful information it's expecting. If it doesn't match the format it
> expects, then it throws it away. Tokens will undoubtedly encode all sorts of
> useful stuff that resource servers know how to decode - like format,
> expiration, scope, whatever. The point is that the structure is undefined
> *to the client*.
>
> one token could be SAML, another JSON in one format, another in URL encoded
> name/value pairs.  The PR is having to detect both syntax and semantics.

---

From: John Kemp <[email-masked]>
Date: Mon, 7 Jun 2010 12:39:00 -0400

> OAuth2 has a field for AS-to-PR communications via (but opaque to) the client: access_token. Any format indication (like a variety of other details) that an AS wants to convey to the PR via the cli…

I take your point, I think, that the format is a description of the token, and should thus be "inside" the token. 

However, in this case, what we're calling a token is simply an "opaque string" - an opaque string only becomes a token via some mapping made by some entity (one or more entities) able to make the mapping. 

I think it would be more accurate to call what we currently call token a "token_string" or "artifact" or anything else that indicates that the thing you're passing around often isn't the token itself but a compressed version, or pointer to the actual token. But if we keep calling it token, I still think we should be clear on what it actually is. 

I don't think the "format" which defines the mapping from token string to token belongs inside the token string. 

>  access_token=saml.fhHFhgf6575fhgFGrytr

What is the advantage of doing it this way over having a separate field? What if the format is a URI? 

> There can be an IANA registry for prefixes if that is helpful.

Personally, I'd like to see this solution be a bit more distributed, and a registry isn't.

- johnk

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 8 Jun 2010 10:25:46 +1000

John,

> What is the advantage of doing it this way over having a separate field?

Client simplicity (code and mental model).

> What if the format is a URI?

That is a choice between the AS and PR that is irrelevant to the client app -- so why should the client app have to worry about it (and any extra escaping it entails).

> Personally, I'd like to see this solution be a bit more distributed, and a registry isn't.

I hope there aren't so many common, shared formats that a distributed solution is necessary. But you can make the prefix a domain name, or a base64url-encoded URI, or a hash of a URI etc if you really want it distributed.

Andrew Arnott said:
> But token_format is not the idea I think.  It's more like token_origin.

I hope we don't need a 3rd "opaque string" for the client app to transfer from the AS to PR.

--
James Manger

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 8 Jun 2010 12:29:57 +0900

> A separate spec defining standard tokens has been discussed.

Where is it being done?
I am very interested in it.

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

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 8 Jun 2010 15:06:32 +0900

+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

---

From: John Kemp <[email-masked]>
Date: Tue, 8 Jun 2010 06:45:20 -0400

> Client simplicity (code and mental model).

I think the difference in simplicity between one parameter and two is not such that it requires munging the two together.

The token_string and the token_format are two different parts of the token.

- johnk

---

From: Luke Shepard <[email-masked]>
Date: Tue, 8 Jun 2010 06:58:07 -0700

> The token_string and the token_format are two different parts of the token.

If you look through my emails, I provided code samples to illustrate that two parameters is in fact more complex than one. Much of the simplicity of OAuth 2.0 is achieved by unifying myriad parameters into a single access token. Much of that is lost by splitting it apart again.

We can't even agree what we want or how to split it - some want origin, some want format, still others probably want something else. No, the whole point is it's up to the provider and the resource to unify them and it's opaque to the client.

Again: can you provide a specific, real-world example where this is necessary? I'd rather not deal in hypotheticals. I've already answered the case of a hypothetical endpoint that accepts both SAML and JSON-encoded tokens.

---

From: George Fletcher <[email-masked]>
Date: Tue, 08 Jun 2010 10:17:11 -0400

On 6/8/10 9:58 AM, Luke Shepard wrote:
> Again: can you provide a specific, real-world example where this is 
> necessary? I'd rather not deal in hypotheticals. I've already answered 
> the case of a hypothetical endpoint that accepts both SAML and 
> JSON-encoded tokens.
I believe one such case is person-to-person sharing where person A is 
NOT part of the same network as person B.

If I have a protected resource at photos.example.com and I want to share 
with someone who is NOT a member of photos.example.com there are only a 
couple of options...

1. Today's method: security by obscurity with "non-guessable" URLs 
emailed to person B

2. Use OpenID and force Person B to "sign in" to photos.example.com 
(effectively establishing a relationship with photos.example.com that 
they might not want)

3. Have photos.example.com be able to accept a token from person B's 
authorization service saying this is person B when accessing the 
protected resource.

Option 3 is a much better experience for the user and simpler to 
implement for any client that person B is using. However, this requires 
that photos.example.com be able to read and understand the token from 
person B's authorization server (AS). Hence we need some way to 
associate origin and format with the token.

Personally, I think that using XRD the origin server could expose a 
"dumb mode" token validator such that resource owners that don't now how 
to process the token natively could still validate the token and get 
some minimal information.

Thanks,
George

Some additional thoughts and links: 
http://practicalid.blogspot.com/2010/05/identity-as-attribute.html

---

From: Brian Eaton <[email-masked]>
Date: Tue, 8 Jun 2010 08:32:04 -0700

On Tue, Jun 8, 2010 at 7:17 AM, George Fletcher <[email-masked]> >
2. Use OpenID and force Person B to "sign in" to photos.example.com
> (effectively establishing a relationship with photos.example.com that they
> might not want)
>
> authorization service saying this is person B when accessing the protected
> resource.

These two options seem equivalent to me.

They certainly bring up the same user experience challenges.

---

From: Brian Eaton <[email-masked]>
Date: Tue, 8 Jun 2010 08:35:45 -0700

On Sun, Jun 6, 2010 at 8:14 PM, Manger, James H > Defining an optional
prefix for access_token values to indicate the format would work well.
> A service that will never need token format interop doesn't need to using any prefix (empty or otherwise), and can use dots however it wants.

Slick!

Andrew brought up a good point about interop between multiple token
issuers.  But that can be solved by data *inside* the access token.
If a server really needs to crack open tokens from multiple issuers,
it would work like this:

parse the format off the front
decode the rest of the token according to the format
crack open the token to find a pointer to the issuer
use that information to verify the token

I don't think the prefix needs any kind of URI or namespacing.  New
token formats should be extremely rare.

Cheers,
Brian

---

From: George Fletcher <[email-masked]>
Date: Tue, 08 Jun 2010 11:40:50 -0400

Here is where I see the differences...

#2 forces "person B" to go through an authentication event at 
photos.example.com

while #3 allows the client "person B" is using to get the access token 
at time of authentication to the client.

So, for #2 "person B" will likely have to do 2 authentication events (1 
to the client and 1 to photos.example.com). While with #3, "person B" 
only has to do 1 authentication event (to the client).

Thanks,
George

On 6/8/10 11:32 AM, Brian Eaton wrote:
> On Tue, Jun 8, 2010 at 7:17 AM, George Fletcher<[email-masked]>  >