Phil, that's not a fair comparison. What I've done is a fundamentally
different kind of breaking change than the one you're asking for, though.
To explain more concretely: The change I agreed to make here was to
remove two underspecified values (of five listed) to a parameter that is
intended to be extensible. The extensions to DynReg that are using these
values (like OIDC registration) can then define them fully (like they
already are). That is a good change, and prompted by the good discussion
and feedback you've given here. That doesn't mean that the parameter
itself is "broken", and I think it's entirely another thing to remove
the parameter wholesale when it has proven utility. Getting rid of it
entirely would make it an OIDC-only parameter, when people are using it
in non-OIDC contexts.
I acknowledge the concerns that you have with the draft, and I thank you
for your feedback so far. However, I don't agree with your conclusions
regarding those concerns. I do look forward to any concrete proposals
you'll have later this week that will help further this discussion.
-- Justin
On 05/20/2013 02:27 PM, Phil Hunt wrote:
Further to my last...
Justin has already committed to breaking changes. This may have been
lost or buried in the long review thread.
Specifically - The client authentication types specified are
undocumented (client_secret_jwt and private_key_jwt) as they were all
Holder-of-Key authentication methods. The OAuth drafts currently only
have bearer drafts and dyn reg does not support these profiles.
Justin has acknowledged this.
It seems to me, that since the token_endpoint_auth_method is broken,
the current implementations are actually implementing the draft
correctly or servers are just ignoring it the parameter.
There are concerns with this draft. I plan to make specific
suggestions (some breaking) later this week.
Phil
@independentid
www.independentid.com <http://www.independentid.com>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
On 2013-05-20, at 10:51 AM, 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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
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
