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 phil.h...@oracle.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
