Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

Hi, A few rewording suggestions; *section-6.2* Original: The Application Server SHOULD use the OAuth 2.0 authorization code grant to initiate a request *request *for an access token... Suggestion: The Application Server SHOULD use the OAuth 2.0 authorization code grant to initiate a request for

[OAUTH-WG] Transaction Authorization

I have requested time to present Transactional Authorization (the XYZ project) at the Montreal meeting in a couple weeks. Ahead of that, I’ve uploaded a new version of the spec: https://tools.ietf.org/html/draft-richer-transactional-authz-02 Additionally, I’ve updated the writeup and examples

Re: [OAUTH-WG] Refresh tokens

For historical references only... the Google model around refresh tokens and the AOL model around refresh tokens were slightly different. So I proposed a bunch of the OIDC text around refresh tokens and offline access to allow for both models. At AOL, the model was that refresh_tokens were

Re: [OAUTH-WG] Refresh tokens

I'll just add a couple more thoughts around refresh_tokens. 1. I agree with David that refresh_tokens are valuable in an "online" scenario and should be used there. 2. To use a refresh token at the /token endpoint, client authentication is required. This is where it gets difficult for

[OAUTH-WG] historical note regarding use of url fragment in OAuth for Browser-Based Apps draft -02

re: 9.8.7 . Historic Note Historically, the Implicit flow provided an advantage to single-page apps since JavaScript could always arbitrarily read and manipulate the fragment portion of the URL without

Re: [OAUTH-WG] Refresh tokens

> On Jul 8, 2019, at 8:39 PM, Aaron Parecki wrote: > > These are all very good points! I think the challenge here is figuring out > where this kind of guidance is most appropriate. > > It does seem like some of these issues are unique to a browser environment > (particularly where the