Clarify requirements for Client ID Metadata Document Services

[ThisIsMissEm]

The way in which a Client ID Metadata Document Service works is up to the implementer of that service, the only requirement is that they return valid Client ID Metadata Documents for the client_id URIs that they provision, or return an appropriate status code for an error response.

I do have a reference implementation of a Client ID Metadata Document Service which is open to the general public, but enforces the additional restrictions that Bluesky's AT Protocol has for Client ID Metadata Documents, which can be found at https://cimd-service.fly.dev — however, I want to be clear that that API isn't a standard API.

[OllieJC]

What's the rationale for including "Document Service" at all? Could that possibly be completely out of scope?

[ThisIsMissEm]

@OllieJC because one of the biggest questions we received when introducing this to developers was "how the heck do I use this in development?"

So the answer we're presenting is "you use a service to provision a Client ID Metadata Document on a publicly accessible URL"

[OllieJC]

Thanks @ThisIsMissEm! I do wonder if it is unnecessary though - I'd hope that folks could figure that out relatively trivially using GitHub pages etc. That said, I've just spun this up: https://path2json.olliejc.workers.dev/