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 flow is NO client authentication. So what technical or operational benefit of registering an execution instance?
Maybe, the horse has left the barn. But I don't see that as a reason to standardize an unsafe or pointless practice. I'm not saying it is pointless. I'm just not clear on what the benefit is. I am curious about Josh's use case. How is the client code developed, distributed, and deployed? Are there already inherent mechanisms where OOB deployment registration is easy to achieve? IOW Each client use can easily obtain an OOB client_id. Josh expresses he needs to register, but the question I am asking is why? It seems that in his case, the code being downloaded must be coming from a common trusted source. If so, what benefit is gained with dynamic registration for these clients. They should just use a static client_id -- even something akin to the initial client assertion Justin talks about. >From an operational aspect, issuing per execution context client_ids (and >potential per client_id registration access tokens), etc per client seems to >be wasteful for both the implicit client code and especially the AS/Resource >SPs. Phil @independentid www.independentid.com [email protected] On 2013-05-24, at 2:38 PM, John Bradley wrote: > 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 etc) > > Implicit as you well know relies on registration of the redirect URI to > identify the client. There may be multiple JS apps in browsers all using JS > from the same redirect URI, but I don't think that should preclude the > backend website from using an API to register. > > Turning off dynamic registration entirely for implicit flow is overkill. A > registration server is free to not allow dynamic registration of implicit > clients if that is it's policy. > > In general I have a hard time seeing implicit clients with a server component > using dynamic registration directly. I suppose there may be HTML5 based > clients that are loaded as browser extensions and use implicit, without > having a server based redirect. Those can be as long lived as any native > app. If clean up is an issue it is one for code flow as well. > > John B. > > On 2013-05-24, at 2:35 PM, Phil Hunt <[email protected]> wrote: > >> 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 instance. >> >> A few issues to consider: >> * Implicit clients typically run in browsers (javascript). Do we really want >> each occurrence of a browser running a client to register? >> --> This could mean even the same browser running implicit flow repeat >> times, would register repeatedly. >> --> If registration occurs per occurrence, what is the value? >> >> * What use cases typically occur for deployment against different AS and >> Resource API instances? >> --> Eg. I can see a javascript component of a web site that uses a >> corresponding resource API. So it may be possible that the javascript and >> the resource API are running in the same domain. In this case, the >> javascript code, though written as part of a shared library/distribution, is >> still bound to a configured AS deployment. Is it really dynamic? If this is >> the case, wouldn't an OOB registration that updates the client_id in the >> deployment be better suited? >> --> Are there any examples of javascript clients that need to connect to >> one or more AS servers on a truly dynamic basis? >> >> * Is there a DOS attack possible (even unintentionally) because implicit >> clients will start to register frequently creating huge numbers of >> client_ids that cause spin-off provisioning issues depending on how AS >> registration, token, and policy systems are implemented? >> >> Apparently OIDC and UMA had these profiles supported before, but I'm really >> trying to understand why implicit clients should have dynamic registration >> support. Would appreciate any discussion on this. At minimum, there are >> probably some security considerations we need to think through and document. >> >> Thanks for your comments, >> >> Phil >> >> @independentid >> www.independentid.com >> [email protected] >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
