It is my strong opinion that giving each execution a client_id makes things
much worse.
Again now we cant tell who the risky players are since each client is
anonymized through registration process.
This is just not securable by any means. IMHO.
Phil
On 2013-05-28, at 8:42, Justin Richer
The main problem comes with establishing the client_id across multiple
auth servers, not across multiple copies of the code. One of the key
things that the DynReg spec does is establish a client_id for a client
at an AS, and indeed the trigger condition for using it is generally
"I'm a client a
John/Josh,
I am afraid it is still not clear to me what is the value of implicit client
dynamic registration. If you allow dynamic registration of a client, each
client, then each client can specify random redirect_uri's. This would seem to
be a major issue. The whole point behind implicit flo
Phil,
I think the horse is out of the barn on implicit flow.
Many websites use implicit rather than code now, it is no worse, and perhaps
better than using code flow with a client that is not confidential( though
Dynamic registration can dix the public client code flow problem for native
apps
I can see what you're trying to do there, but I agree that it's a bit of a
non-starter. It assumes that clients even can be expired (which requires
time-based processing of a client, not something most AS's are set up to do
today, though it's far from impossible). And an in-browser client is lik
I expect this is a non-starter, but dyn-reg *could* allow the client ti
include a "please expire me in xx min" flag in the registration request
(avoiding need for explicit cleanup later).
-J
On Fri, May 24, 2013 at 1:36 PM, Richer, Justin P. wrote:
> I agree with Josh, and I believe that this
I agree with Josh, and I believe that this kind of application should
definitely be supported. One of my goals with the Dynamic Registration draft
was to make it so that it could be used for all the various flavors of OAuth
that people are using today. But that said, I'm not at all against givin
I think this discussion mixes two separable questions:
1. Should dyn-reg support client-side browser-based apps (which need
client_ids for each AS they talk to, even if they only talk briefly and
then throw the credentials away)?
2. Which authorization flows are available to clients?
I have exa
I wanted to bring out a quick discussion to ask the question if it makes sense
to support implicit clients in dynamic registration.
By definition, implicit clients are unauthenticated. Therefore the only purpose
to register an implicit client is to obtain a client_id with a particular AS
instan
