Marius,
>> I wouldn't be surprised if, in some scenarios, the token info gets too big >> to fit in a URI. In that case even the user-agent flow will need to make a >> direct request to get the token info, which is more likely to be delivered >> as JSON. OpenID and SAML have found they need this (eg artefact flows). > In this case the user-agent flow becomes the web server flow, which > does this already, no? The hassle is that the client chooses type=user_agent at the start so the authz server cannot change this to a web_server flow later if the response doesn't fit in the redirect URI. The spec should change this -- allowing the authz server to choose to respond with token details in the redirect URI or with token details available at a token URI. When it is the server's choice, the client needs to handle both possibilities. On the other issues: > parsing JSON in JavaScript can be tricky This is not true. My understanding is that the current versions of Firefox, IE, Opera, Chrome, and Safari all support JSON.parse(). In older browsers you may need to use eval(), but the JSON RFC (and Evan's email) show how to make that safe with 3 lines of code; or use json2.js (available from json.org) that implements JSON.parse() for older browsers. > decoding Base64 is yet one more thing, much more complicated than percent > decoding. Base64 is so widely used that I don't consider it unreasonable to require. Base64url is less common, but just as simple. I don't think it is more complicated that %-decoding. -- James Manger _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
