Hi Neil, Oh, my bad, it is indeed a MUST (NOT), I think when I drafted that like I originally had it as a SHOULD NOT & got a little mixed up.
I contemplated such a prefix, but thought authorization_ implied that, since only users have authorization grants? Though I'm not strongly tied to the name, just the concept. I could certainly add that language around not increasing scope, however, I thought that was perhaps superfluous given OAuth only specifies two mechanisms for changing scope (a new authorization grant or changing scope via refresh grants within the bounds of the original grant) Yours, Emelia > On 18. Nov 2025, at 10:13, Neil Madden <[email protected]> wrote: > > > > >>> On 17 Nov 2025, at 23:53, emelia <[email protected]> >>> wrote: >>> >> >> >> >> I'd certainly accept some language along these lines, I tried to keep the >> language focused only on providing a discovery mechanism for this page, as >> to not prescribe anything to Authorization Servers. >> >>> I think it would be useful to have some non-normative recommendations for >>> how AS, RS, or clients should expose this URL to the users, e.g. on the >>> consent page for the AS. ("You're granting these permissions; here's how to >>> manage/remove them.") >> >> The only SHOULD is around native apps & not opening this URI in a webview, >> since that could allow the client application to exfiltrate the user's >> actual credentials. > > It’s a MUST NOT in your draft, which seems appropriate to me. > > I like the draft. Two suggestions: > > - Add a user_ prefix to the metadata name or similar to make clear that this > is intended for end-users to access. > > - Maybe add some wording that the page should only allow viewing and revoking > grants, not increasing scope or adding new grants (which would use a normal > OAuth flow). > > Also, an assumption is that the same URI is used for all users? > > — Neil > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
