-1
Let’s not continue propagating these issues
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Torsten Lodderstedt
Sent: Thursday, August 15, 2013 10:32 PM
To: John Bradley; Phil Hunt
Cc: m...@gluu.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] OX needs Dynamic Registratio
The yak needs to be sheered to make way for better hair.
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Friday, August 16, 2013 7:07 AM
To: Torsten Lodderstedt
Cc: m...@gluu.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] OX needs Dynamic Registration: p
-1
I would say the analogy is this:
Clarify client_id = shave the yak to get the fur
Dyn reg = skin the yak to make access to the fur easier.
The yak in this case is the SP.
Dyn reg works but the sp dies under the load in the process.
Phil
On 2013-08-16, at 7:06, Justin Richer wrote:
> +
Before everyone gets excited, all John and was referring to was providing
further definition on client_id that allows scenarios where the id isn't issued
by the AS but rather a federated entity.
This in no way changes how 6749 works.
In particular for javascript clients it would avoid the inc
+1
Let's not shave a yak quite yet.
On 08/16/2013 01:32 AM, Torsten Lodderstedt wrote:
+1
Dyn reg should fit into the OAuth system as it is now, which uses
client ids and secrets. A (probably) improved OAuth is a completely
different topic. Let's handle it separately.
John Bradley schri
From what I recall, the intent was to use form parameters in the http
entity body, in order to prevent query param leaking into logs (or
something like that). But I don't think there was intended to be a
prohibition on query parameters on POST. Since the auth endpoint is
almost exclusively acce
