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