Subject: Re: [OAUTH-WG] Call for Adoption: Stateless Client Identifier for OAuth 2

From: Mike Jones <[email-masked]>
Date: Thu, 4 Feb 2016 06:29:39 +0000

I support adoption of this document by the working group as either an experimental or information specification.

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Tuesday, January 19, 2016 4:05 AM
To: [email-masked]
Subject: [OAUTH-WG] Call for Adoption: Stateless Client Identifier for OAuth 2

Hi all,

this is the call for adoption of Stateless Client Identifier for OAuth 2, see
https://tools.ietf.org/html/draft-bradley-oauth-stateless-client-id-02

Please let us know by Feb 2nd whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group.

Ciao
Hannes & Derek

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Feb 2016 13:37:14 -0300

I support it.

I have always thought of this as informational.  It is not the only way to do it, and has no real interoperability impact.

John B.
> On Feb 4, 2016, at 3:29 AM, Mike Jones <[email-masked]> wrote:
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 6 Feb 2016 12:43:01 +0100

+1

---

From: William Denniss <[email-masked]>
Date: Sat, 6 Feb 2016 10:56:57 -0800

+1 to adopt.

I don't think we're planning to use this, but it looks useful and doesn't
harm interoperability so I support it.

On Sat, Feb 6, 2016 at 3:43 AM, Torsten Lodderstedt <[email-masked]
> wrote:

>> I have always thought of this as informational.  It is not the only way
>> to do it, and has no real interoperability impact.
>>
>> John B.
>>
>>> I support adoption of this document by the working group as either an
>>> experimental or information specification.
>>>
>>>                                 -- Mike
>>>
>>> Please let us know by Feb 2nd whether you accept / object to the
>>> adoption of this document as a starting point for work in the OAuth working
>>> group.
>>>
>>> Ciao
>>> Hannes & Derek
>>>
>>>

---

From: Roland Hedberg <[email-masked]>
Date: Sun, 7 Feb 2016 20:07:55 +0000

+1

> 6 feb 2016 kl. 19:56 skrev William Denniss <[email-masked]>:
> 
> +1 to adopt.
> 
> I don't think we're planning to use this, but it looks useful and doesn't harm interoperability so I support it.
> 
> On Sat, Feb 6, 2016 at 3:43 AM, Torsten Lodderstedt <[email-masked]> wrote:
> +1
> 
> 

”Everybody should be quiet near a little stream and listen."
From ’Open House for Butterflies’ by Ruth Krauss

---

From: Justin Richer <[email-masked]>
Date: Sun, 7 Feb 2016 18:06:21 -0500

There's already support for this, but just a quick reminder to the 
working group that we already hint at this capability in RFC7951:

    In some cases, authorization servers MAY choose to accept a software
    statement value directly as a client identifier in an authorization
    request, without a prior dynamic client registration having been
    performed.  The circumstances under which an authorization server
    would do so, and the specific software statement characteristics
    required in this case, are outside the scope of this specification.

(Last paragraph of section 2.3)

  -- Justin

---

From: John Bradley <[email-masked]>
Date: Mon, 8 Feb 2016 10:04:03 -0300

Yes this is an example of how you could do it inside the existing specs.  

I guess you could look at it as token transformation for software statements.

This and signed state were created based on developer feedback that we tell them that they need to do something or that they can do something in spec language, but they want an example of how it can be done.

I expect may of them will look at this, and do it some other way that they think is better, but this gives them a start.

John B.

> On Feb 7, 2016, at 8:06 PM, Justin Richer <[email-masked]> wrote:
> 
> There's already support for this, but just a quick reminder to the working group that we already hint at this capability in RFC7951:
> 
>>> 6 feb 2016 kl. 19:56 skrev William Denniss <[email-masked]> <mailto:[email-masked]>:
>>> 
>>> +1 to adopt.
>>> 
>>> On Sat, Feb 6, 2016 at 3:43 AM, Torsten Lodderstedt <[email-masked]> <mailto:[email-masked]> wrote:
>>> +1
>>> 
>>> 
>>> On Feb 4, 2016, at 3:29 AM, Mike Jones <[email-masked]> <mailto:[email-masked]> wrote:
>>> 
>>> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Hannes Tschofenig
>>> To: [email-masked] <mailto:[email-masked]>
>>> https://tools.ietf.org/html/draft-bradley-oauth-stateless-client-id-02 <https://tools.ietf.org/html/draft-bradley-oauth-stateless-client-id-02>
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>