As it says in the draft, this could be used with dynamic registration, manual registration, or any other method of registration. How you get the client_id and the nature of the client_id are orthogonal to each other.
As such, you could easily issue this structured/signed stateless client_id in response to a signed software statement presented during either dynamic registration (which really should be a proper extension of dynamic registration). Alternatively, you can issue this client_id from a manual registration step and then you don't need to do a dynamic registration at the AS at all, since the AS can recognize and validate the contents of the client_id (because it's completely stateless). -- Justin On Oct 21, 2013, at 10:21 AM, Phil Hunt <phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote: I am assuming that this draft fits with the dyn reg draft. It makes the assumption that every single client is somehow potentially different in terms of registration. This draft encodes the registration values in the JWT so that stateless registration can be achieved. Dynamic registration takes a different view from client association, in that dynamic registration has no notion of fixed client software releases that are deployed many times. As such there is no fixed registration profile. Every client is potentially different. In contrast Client Association + Software statements, clients are identified as a particular software and are fixed. Have I read this correctly? >From a policy perspective, how would a service provider handle registration of >clients that are all potentially different? Why would individual clients need >to differ in registration (other than in the tokens negotiated with a >particular deployment SP)? Phil @independentid www.independentid.com<http://www.independentid.com/> phil.h...@oracle.com<mailto:phil.h...@oracle.com> On 2013-10-14, at 5:01 PM, John Bradley <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>> wrote: A new version of I-D, draft-bradley-stateless-oauth-client-00.txt has been successfully submitted by John Bradley and posted to the IETF repository. Filename: draft-bradley-stateless-oauth-client Revision: 00 Title: Stateless Client Identifier for OAuth 2 Creation date: 2013-10-15 Group: Individual Submission Number of pages: 4 URL: http://www.ietf.org/internet-drafts/draft-bradley-stateless-oauth-client-00.txt Status: http://datatracker.ietf.org/doc/draft-bradley-stateless-oauth-client Htmlized: http://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00 Abstract: This draft provides a method for communicating information about an OAuth client through its client identifier allowing for fully stateless operation. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>. The IETF Secretariat _______________________________________________ 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
