Yes. But that does not use the signed jwt assertion which "locks" the 
registration profile.  

Phil

> On Oct 21, 2013, at 10:56, Mike Jones <[email protected]> wrote:
> 
> For what it’s worth, the latest public dynamic registration working group 
> draft has software_id and software_version fields to allow statements to be 
> made about the fixed client software releases that are deployed many times, 
> of which you speak.
>  
>                                                             -- Mike
>  
> From: [email protected] [mailto:[email protected]] On Behalf Of 
> Phil Hunt
> Sent: Monday, October 21, 2013 10:21 AM
> To: John Bradley
> Cc: oauth list
> Subject: Re: [OAUTH-WG] FYI per a request on the last conference call, this 
> is a method for making client registration stateless.
>  
> 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
> [email protected]
>  
> On 2013-10-14, at 5:01 PM, John Bradley <[email protected]> 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.
> 
> The IETF Secretariat
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
>  
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to