There are a couple of potential approaches to this. You can either use dynamic registration to get a new client_id for each instance, or you can tie instance-specific information to a single client_id.
In the former case, you can protect the registration endpoint with developer key of some kind. This key represents the class of clients and provides an audit trail for registration. In connect (and with the new dyn-reg draft I'm working on uploading this week) we're using an OAuth2 Bearer token for this use. By tying the instance-specific client_ids to the single root developer key/token, you can limit how many instances you want to support of any client/user combination. In the latter case, you can use the instance extension draft (http://tools.ietf.org/html/draft-richer-oauth-instance-00 -- needs to be updated but the basics are there) to send information to the Authorization Endpoint. Here, you use the same client_id for each client instance, which makes it trivial to track and limit the client/user combinations. But the extra instance information that the client provides here can help you differentiate the instances. -- Justin On Oct 19, 2012, at 11:22 AM, Pedro Felix wrote: I have a native app scenario where - There are multiple app instances - The same user user can have multiple app instances (phone, tablet) - I would want to use confidential clients - the native app instance dynamically receives the client_secret - There should be a way to limit the number of app instances that are created. For instance, one could associate an app instance to the user's email. Namely, I would like to explore the idea that an app instance is something that is simultaneous associated with the client app but also to the user (resource owner). Thanks Pedro On Fri, Oct 19, 2012 at 3:53 PM, Maciej Machulak <maciej.machu...@cloudidentity.co.uk<mailto:maciej.machu...@cloudidentity.co.uk>> wrote: Hi Pedro, With reference to your question posted on the OAUTH WG regarding dynamic registration of OAuth clients, could you please provide us with the description of your use case. We've implemented dynamic registration on one of our systems based on the specification that we've co-authored (http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00). It would be great to learn more about what you're trying to achieve and if we can help. Thanks, Maciej _______________________________________________ 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
