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

On Jun 6, 2010, at 11:14 PM, Manger, James H wrote:

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

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. 

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

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

> 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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth