I strongly support making authz server management pages more easily
discoverable by users, as it is a persistent problem. (How many of you have
visited https://myaccount.google.com/connections before? How did you find
it?) Putting it in authz server metadata seems like a good start for things
that can be easily specced out, but it will still be up to the client or RS
to expose it to users.
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.")
On Tue, Nov 18, 2025 at 8:36 AM Aaron Parecki <aaron=
[email protected]> wrote:
> > Naïvely I look at this as similar to me putting a "Configure all your
> Google Allowed Applications" button in my app that lets users log in with
> Google, and I can't think of a reason why I would want to do that.
>
> "Log in with Google" isn't the right way to look at it, that's why you
> can't think of a reason you want to do it. A better example would be an app
> that accesses Google resources, but Google doesn't necessarily have to be
> the way the user logged in to the app.
>
> But the scenario described in this thread is closer to a first-party app
> anyway because the app _is_ the primary way the user accesses their
> resources at the API.
>
> The only real argument against adding this parameter would be that it
> isn't actually a generic OAuth problem, like trying to argue that it's
> actually an ATProto-specific concept. Another example of that would be a
> Wordpress app that you can point at an arbitrary Wordpress server already
> needs to know the Wordpress-specific API endpoints to manage content, so
> this could be treated as another Wordpress-specific endpoint.
>
> But clearly both of these scenarios would benefit from the same mechanism,
> and the OAuth grants _are_ part of OAuth, so it makes sense for it to be an
> authorization server metadata property.
>
>
>
> On Mon, Nov 17, 2025 at 3:23 PM Warren Parad <[email protected]> wrote:
>
>> I think it makes sense for us to fully understand a use case before just
>> diving in. If we can envision the problem holistically, then we can ensure
>> that we are designing a forward compatible protocol. It's always a mistake
>> to "throw one line in the metadata registry", if in the end it doesn't
>> actually solve the complete problem space.
>>
>> That being said, if we are confident that we understand the whole
>> problem, and most paths it could take in the future, then it does make
>> sense. But at least, I don't have the confidence to say personally, *"I
>> understand the whole problem"*. And from what little of the problem I do
>> understand, it doesn't make sense to me. This just tells me that I don't
>> understand it well enough like you do.
>>
>> Since you have a generic oauth client, would you be able to share more
>> about how that client works, and under which situations you might expect a
>> user to want to navigate to AS that you don't control? Naïvely I look at
>> this as similar to me putting a "Configure all your Google Allowed
>> Applications" button in my app that lets users log in with Google, and I
>> can't think of a reason why I would want to do that. That is "what's the
>> user story?" Would you be able to share the user story you are providing
>> support for, for the users of the implementers of your client? That would
>> be really helpful for me.
>>
>> Thanks!
>>
>> On Tue, Nov 18, 2025 at 12:04 AM Michael Sweet <msweet=
>> [email protected]> wrote:
>>
>>> Warren,
>>>
>>> > On Nov 17, 2025, at 4:36 PM, Warren Parad <wparad=
>>> [email protected]> wrote:
>>> >
>>> > For sure, it's just the connection from the client to the AS page,
>>> that is at least weird for me.
>>> >
>>> > Users absolutely want to find this page. I just don't think non-first
>>> party clients should be providing that way to make it happen though. Which
>>> brings me back to the problem of when would it ever get usage. If we think
>>> about all the clients of ATProto being first party apps though, then this
>>> makes a lot more sense.
>>>
>>> So as a "generic OAuth client" implementor (specifically for CUPS, but
>>> anyone can use the C API), I am 100% in favor of providing metadata that
>>> allows my client software to provide "first party" security
>>> capabilities/functionality for whatever OAuth provider they choose. I also
>>> don't think adding one line to the IANA metadata registry is a big deal,
>>> with or without people lining up to support it, but for the record I'd
>>> support it in CUPS.
>>>
>>> ________________________
>>> Michael Sweet
>>>
>>> _______________________________________________
> 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]
