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
