Feedback: Developer Experience Improvement

[ciamshrek]

While building a proof of concept, we explored the feasibility of this for public developer / development clients.

One interesting scenario CIMD allows is for reserved developer / testing / experimental only applications to be hosted at an https url https://developer.example.com/client_id.json that the AS Controls which can then be left for any developers, alternative to a hard-coded http://localhost client.

There are a few places where this comes in handy:

• Native Applications Development for Public Clients: Instead creating a per-developer *.plist file with the client_id for each instance of the application is simply https://developer.example.com, with all the required properties. This means a developer can just git clone and run the app.

• Open to External Developers: If desirable for public clients. A CIMD document can be used to explicitly identify open-to-all developer usage eg https://external.example.com. With allowed callback to localhost etc.

For instance an AS for an MCP Server, would not need to support an open-ended approve list, but would facilitate clients which do not have an https url yet (cli-s, etc) to be able to obtain credentials.

These clients can then have a different / stronger consent flow, instead of just the consent prompt the AS can require explicit intent and approval of developer client.

Instead of using localhost this also allows these clients to be updated, managed by leveraging the existing best practices.

[aaronpk]

This sounds like a simpler version of the "Service" mentioned in this section: https://drafts.aaronpk.com/draft-parecki-oauth-client-id-metadata-document/draft-parecki-oauth-client-id-metadata-document.html#section-4.2 Essentially this is a single hard-coded development client. I like the idea, I wonder if we can describe the tradeoffs between the two options, and just say that either one is fine.

[ciamshrek]

Pretty much, although instead of hard-coding, just relying on commodity Hostable JSON Documents seems a lot more desirable, since it allows have separate services each for specific purpose.

[ThisIsMissEm]

A document on http://localhost would not be valid, since the Authorization Server cannot fetch it (unless the authorization server is also on localhost — that's a separate issue), however a remote Client ID Metadata Document could indeed redirect to a localhost URI.

I'm not sure what the following comment refers to:

Essentially this is a single hard-coded development client.

The Client ID Metadata Document Service essentially says "I'll host Client ID Metadata Documents for developers with a few considerations (e.g., " (Development)" added to client_name and acknowledging that an AS may warn users when authorizing this particular client.

[ThisIsMissEm]

I've actually now built an example of said "Service" in Section 4.2: https://cimd-service.fly.dev/