The "can" works better, agreed. Thanks!
ᐧ
On Sat, Aug 29, 2020 at 8:25 AM Justin Richer wrote:
> Thanks, Dick. I agree with removing the excess parenthetical, but I
> intentionally avoided using a lowercase “may” in the middle of the
> text (in favor of “can”) to avoid normative-sounding non-no
I gone draft this section.
> Am 29.08.2020 um 17:22 schrieb Justin Richer :
>
> I completely agree with the utility of the function in question here and it
> needs to be included. I’m in favor of creating a dedicated section for
> redirect_uri management, so that we can explain exactly how and
Thanks, Dick. I agree with removing the excess parenthetical, but I
intentionally avoided using a lowercase “may” in the middle of the text (in
favor of “can”) to avoid normative-sounding non-normative language, so I’d
recommend that change be kept:
Implementers should be aware that a token in
I completely agree with the utility of the function in question here and it
needs to be included. I’m in favor of creating a dedicated section for
redirect_uri management, so that we can explain exactly how and why to relax
the requirement from core OAuth. In addition, I think we want to discuss
> On 11. Aug 2020, at 08:20, Karsten Meyer zu Selhausen
> wrote:
>
> Hi all,
>
> I think we all agree that proper countermeasures of mix-up attacks should
> definitely be part of the BCP and 2.1 due to the severe impact successful
> mix-up attacks have.
> Theoretically speaking every client
> On 11. Aug 2020, at 23:55, Brian Campbell
> wrote:
>
> Hi Francis,
>
> My apologies for the tardy response to this - I was away for some time on
> holiday. But thank you for the review and feedback on the draft. I've tried
> to respond inline below.
>
>
> On Fri, Jul 31, 2020 at 5:01 P
>
>
> ¶6: Does the AS really have "the ability to authenticate and authorize
> clients”? I think what we mean here is "the ability to authenticate clients
> and validate client requests”, but I’m not positive of the intent.
>
> I think the intent is that the AS can check whether a client
You are making a good point here. The reason we added the one time use
constraint was the fact the client will include parameters supposed to be used
only once, e.g. the PKCE code_challenge. For a traditional authorisation
request, we would recommend the client to use a per transaction (== one t
