Phil the token_endpoint_auth_method is not broken. We have agreed that the methods defined in Connect and not in the base spec will be registered separately in the registry rather than being in the base spec. I don't think that is broken.
They are documented in Connect, that works for connect but less so for people who don't use that spec, so they go in the registry. They are NOT related to HoK in any way they are just the JWT assertion profile with keying specified for symmetric and asymmetric. The bearer profile as it is needs both sides to agree on keying otherwise it tends not to work. Some similar generic profile will need to be defined for JWT and SAML assertions to get interoperability outside of connect. So this is not a breaking change, just a slight shuffling of where things are. John B. On 2013-05-20, at 2:27 PM, Phil Hunt <phil.h...@oracle.com> 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 > 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> 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] On Behalf Of >>> Justin Richer >>> Sent: Monday, May 20, 2013 9:42 AM >>> To: Phil Hunt >>> Cc: 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> 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> 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 >>> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
