On Jun 7, 2010, at 8:25 PM, Manger, James H wrote: > John, > >>> access_token=saml.fhHFhgf6575fhgFGrytr > >> What is the advantage of doing it this way over having a separate field? > > 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 > >> 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). > > >>> 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. > > 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
