Public and Confidential Clients should be explained

[jmandel]

... with specific mention of authorization_code and client_id

(Request from Adrian.)

[jricher]

We can reference the text from OAuth (RFC6749) for this purpose. Must be careful to note that everybody gets a client_id and that the client_id is public.

[jmandel]

The OAuth spec is clear but pretty sparse on this question. I'd imagine we'll need some higher-level discussion on how to know which kind of client you have. We may also want to consider possible interplay between Client Class vs. Client Instance here. E.g. should we allow a client class to have public as well as confidential instances? Or should we impose restrictions to help providers reason at the class level?

[jricher]

I think a discussion of configuration-time secrets vs. runtime secrets can help this, as well as notions of which flows you can use for each case.

I think we'll want to specify that a single client class have one set of behavior -- we can do this by requiring the "token endpoint auth method" parameter be specified at the Client Class level (and not overridable by a Client Instance).

[jmandel]

Closing (duplicated by #4)