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