We added this text to give examples of how to form the URL so that
server developers would be able to see common patterns. Without this
text, I heard from developers who thought that it *must* require a
client_id query parameter, or that it *must* be a URL template, or that
it *must* be different from the client registration endpoint at all.
None of those are the case. The fact that there are several valid ways
to implement this shows that we need some kind of guidance, and the fact
is that it doesn't actually matter *what* the URL is at the end of the
day as long as the client doesn't manipulate it and the server can make
sense of it.
They also help enforce the point that clients MUST use the URL as-is
without adding anything to it. There were some folks who thought that
they client would need to take the URL as given by the server and add a
query parameter to it, and that's not the case.
If this can be written better, I'd appreciate improved text or more
examples, but I don't think that we can delete the guidance.
-- Justin
On 06/05/2013 05:00 PM, Tim Bray wrote:
Section 4.1. Forming the Client Configuration Endpoint URL
Why not discard the last three paragraphs? Server side implementers
have a problem in how to create a client-config endpoint & remember
what it applies to. I can think of several different ways you could
approach this, the spec guidance is superfluous.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
