On Mon, Apr 06, 2020 at 12:05:28PM -0600, Brian Campbell wrote:
> Hi Mike,
>
> Thanks for your interest in the work and review of the draft. As one of the
> too-many authors on the document, I attempt to answer questions and respond
> to comments inline below. Though I admit to not having necessar
I want to add my perspective to the question of audience restriction, below:
One of the problems with implementing audience restriction of RS’s in the wild
has actually turned into a problem of audience identification instead. In other
words, the client needs to know some identifier that the RS
Hey Aaron,
Thanks for today’s update on oauth-browser-based-apps, very useful.
As agreed, here’s the summary of the point mentioned during today’s call.
1. The last paragraph of 6.2 mentions that an access token could be used as
session between the JS frontend and its backend, but no details
Am 06.04.20 um 15:59 schrieb Aaron Parecki:
> Keeping the details in section 4 makes sense. I think why I was
> confused is that there isn't a subheader in section 2 for refresh
> tokens so it's not immediately obvious until you get to section 4.
> What about adding a new subhead in section 2 with
Am 06.04.20 um 16:09 schrieb Aaron Parecki:
>
> The injected authorization code would always refer to a different
> session (started with a different nonce). The client would
> therefore get an ID Token with a different nonce. The assumption
> is that the client would then throw awa
Hi Mike,
Thanks for your interest in the work and review of the draft. As one of the
too-many authors on the document, I attempt to answer questions and respond
to comments inline below. Though I admit to not having necessarily adequate
answers to everything at the ready. And also apologize for th
>
> The injected authorization code would always refer to a different session
> (started with a different nonce). The client would therefore get an ID
> Token with a different nonce. The assumption is that the client would then
> throw away both the ID Token and the access token.
This is true as
Keeping the details in section 4 makes sense. I think why I was confused is
that there isn't a subheader in section 2 for refresh tokens so it's not
immediately obvious until you get to section 4. What about adding a new
subhead in section 2 with just that short summary and referring to section
4 f
Hi Aaron,
Thanks for your feedback!
Am 05.04.20 um 20:42 schrieb Aaron Parecki:
> Section 2.1.1 says:
>
> Clients MUST prevent injection (replay) of authorization codes into
> the authorization response by attackers. The use of PKCE [RFC7636]
> is RECOMMENDED to this end. T
