Brian is right, it's still a MUST NOT. We could relax that to a SHOULD NOT to 
allow for the (still largely theoretical) structured client_id construct to 
change over time. The reason it's how it is right now is that most systems use 
the client_id value as a key into things and funny expect it to change, as was 
discussed at several meetings and on the list already. Current implementations 
of this spec don't use structured client_id values. 

But as this is now tagged as experimental, we could also just publish it as is 
and see if anybody actually tried to deploy those two options together.

-- Justin

/ Sent from my phone /


-------- Original message --------
From: Brian Campbell <bcampb...@pingidentity.com> 
Date:11/14/2014  4:26 AM  (GMT-10:00) 
To: Hannes Tschofenig <hannes.tschofe...@gmx.net> 
Cc: oauth@ietf.org 
Subject: Re: [OAUTH-WG] Meeting Minutes 

My question was not really about the status of 
draft-bradley-oauth-stateless-client-id but rather about 
draft-ietf-oauth-dyn-reg-management allowing for the kind of stateless client 
id that Bradley described in his draft.

And draft-ietf-oauth-dyn-reg-management still has text that says, 'The value of 
the "client_id" MUST NOT change from the initial registration response.' which 
makes it incompatible with the concepts described in 
draft-bradley-oauth-stateless-client-id.

On Thu, Nov 13, 2014 at 8:05 PM, Hannes Tschofenig <hannes.tschofe...@gmx.net> 
wrote:
Hi all,

here is a draft version of the meeting minutes:
http://www.ietf.org/proceedings/91/minutes/minutes-91-oauth

Thanks to Brian Rosen for taking notes.

Comments are welcome!

Ciao
Hannes & Derek


_______________________________________________
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

Reply via email to