Subject: Re: [OAUTH-WG] Meeting Minutes

From: Justin Richer <[email-masked]>
Date: Fri, 14 Nov 2014 06:47:02 -1000

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 <[email-masked]> 
Date:11/14/2014  4:26 AM  (GMT-10:00) 
To: Hannes Tschofenig <[email-masked]> 
Cc: [email-masked] 
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 <[email-masked]> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Fri, 14 Nov 2014 11:39:12 -0700

I'd guess people wouldn't try to deploy those two options together because
it's clearly prohibited.

On Fri, Nov 14, 2014 at 9:47 AM, Justin Richer <[email-masked]> wrote:

> 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 /
>
>
> 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.
>