> 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]
