I don't know offhand a better place or if your specific privacy
consideration is already covered. Honestly, with that comment, I was just
aiming to keep the scope of this document concise and relevant.
On Tue, Oct 11, 2022 at 10:06 AM Denis wrote:
> Hi Brian,
>
> I agree with you that "must not"
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.
Title : OAuth 2.0 Step-up Authentication Challenge Protocol
Authors : Vittorio Bertocci
Hi Brian,
I agree with you that "must not" is more appropriate in that context.
I also agree with you that the "privacy implications of opaque tokens
are inherent to OAuth in general".
However, I have not reviewed all the RFCs and I wonder whether such a
privacy consideration has already been
Thanks Denis, I agree the word "cannot" isn't quite right there. I
struggled with trying to find the right wording (more than I probably
should have) attempting to add a note/reminder without getting into
normative sounding language. But I also wanted to make a firm statement.
Words are hard someti
I forgot to add Dima to the acknowledgements yesterday when doing -04
(thanks Vittorio for catching that). I'll rectify that shortly.
On Mon, Oct 10, 2022, 4:53 PM Brian Campbell
wrote:
> I've published an -04. It has that very minor change. There was also an
> off-list discussion during WGLC th
Hi Brian,
The text states:
Also recall that OAuth 2.0 [RFC6749] assumes access tokens are
treated as
opaque by clients. So, during the course of any token caching
strategy, a client *cannot* inspect the content of the access token to
determine the associated authentication informa
