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
