Phil, I think what you're bringing up is a red herring. Everyone that
does OAuth today does "discovery" in some manner or another, even if
it's not specified to be dynamic like it is in OIDC. Most of the time
this happens manually, out of band. For instance, a number of our
clients here have historically done "discovery" of the server's
capabilities by the client developers just pasting in all the URLs and
parameters to their application's configuration. They get these values
from the server documentation. Just because a piece of information needs
to be known doesn't mean that it needs to be automatically discovered at
runtime.
And yes, we are using it in a plain-OAuth context here, in addition to
an OIDC context. This is using the same server code, for what its worth.
I also take issue with your contention that it will "double the
operational cost" -- how so? If you don't want to enforce the
token_endpoint_auth_method, just don't have your clients send it and
don't have the server return it. It's optional for a reason -- if you
don't like it or have no use for it, don't use it.
-- Justin
On 05/20/2013 01:51 PM, Phil Hunt wrote:
-1
The draft has features that are unclear and will double the
operational cost. The fact that it works doesn't mean it is ready from
the wg perspective.
For the production use, has anyone outside of oidc implemented and
placed in production?
As a non-oidc implementer, I can't make the same assumptions (like
discovery) that oidc umplementers have.
Phil
On 2013-05-20, at 9:48, Mike Jones <michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>> wrote:
The deployment evidence doesn’t support your position, Phil. There
are over a dozen interoperable implementations already deployed.
Those deployments demonstrate that the spec, as written, is already
doing one thing well – enabling clients (as defined by RFC 6749) to
register with Authorization Servers, obtaining client_id and
optionally client_secret values that enable those clients to use
those Authorization Servers. Doing one thing well is exactly what we
should be striving for, and the evidence says that we’ve achieved that.
It’s time to ship it!
-- Mike
*From:*oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>
[mailto:oauth-boun...@ietf.org] *On Behalf Of *Justin Richer
*Sent:* Monday, May 20, 2013 9:42 AM
*To:* Phil Hunt
*Cc:* oauth@ietf.org <mailto:oauth@ietf.org>
*Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration
I, of course, disagree. But that's what we're trying to figure out as
a working group, after all.
-- Justin
On 05/20/2013 12:41 PM, Phil Hunt wrote:
This draft isn't ready for LC.
Phil
On 2013-05-20, at 8:49, Justin Richer <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
But also keep in mind that this is last-call, and that we
don't really want to encourage avoidable drastic changes at
this stage.
-- Justin
On 05/20/2013 11:21 AM, Phil Hunt wrote:
Keep in mind there may be other changes coming.
The issue is that new developers can't figure out what
token is being referred to.
Phil
On 2013-05-20, at 8:09, Justin Richer <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
Phil Hunt's review of the Dynamic Registration
specification has raised a couple of issues that I
felt were getting buried by the larger discussion
(which I still strongly encourage others to jump in
to). Namely, Phil has suggested a couple of syntax
changes to the names of several parameters.
1) expires_at -> client_secret_expires_at
2) issued_at -> client_id_issued_at
3) token_endpoint_auth_method ->
token_endpoint_client_auth_method
I'd like to get a feeling, *especially from
developers* who have deployed this draft spec, what
we ought to do for each of these:
A) Keep the parameter names as-is
B) Adopt the new names as above
C) Adopt a new name that I will specify
In all cases, clarifying text will be added to the
parameter *definitions* so that it's more clear to
people reading the spec what each piece does.
Speaking as the editor: "A" is the default as far as
I'm concerned, since we shouldn't change syntax
without very good reason to do so. That said, if it's
going to be better for developers with the new
parameter names, I am open to fixing them now.
Naming things is hard.
-- Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
