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 giving guidance to how and where to use it with these various flavors.
And regarding the DOS, one thing that the RESTful API here gives us is a means for well-behaved clients to clean up after themselves, where possible. Say the Blood Pressure Grapher is done with its session, it can call the Client Configuration Endpoint and DELETE itself, helping mitigate a flood of one-time-use client_ids. Doesn't necessarily help the case where the clients can't (or won't) clean up after themselves, or with a deliberate DOS, but there's a security consideration about throttling the registration endpoint already. Perhaps we should have something about "if the client_id hasn't been used in any grants in some amount of time, the AS should throw it away". But how long that is and at what level of client_id overpopulation the AS starts to care is way outside of the spec. -- Justin On May 24, 2013, at 4:21 PM, Josh Mandel <jman...@gmail.com<mailto:jman...@gmail.com>> wrote: 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 examples of client-side browser-based apps that fetch blood pressure values from the BlueButton+ API, and do some calculations / visualizations. These apps need to run against any of a large collection of data holders (all of whom implement the same API endpoints), and may learn about new data holders in realtime from an end-user. If we believe this kind of app is a valid use case for dyn reg (Q. #1), then whether it uses Implicit or Code flow (Q. #2) has no bearing on the overall set of concerns you raise. (Unintentional DOS, for example, is no less an issue with the code flow, for browser-based apps that need a throwaway client_id for brief interactions.) And from an app developer's perspective, Implicit flow is simpler and better captures the semantics of a public client. Thoughts? -Josh On May 24, 2013 11:35 AM, "Phil Hunt" <phil.h...@oracle.com<mailto:phil.h...@oracle.com>> 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<http://www.independentid.com/> phil.h...@oracle.com<mailto:phil.h...@oracle.com> _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
