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