Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FCA1B2A86 for ; Mon, 8 Feb 2016 05:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NTt3_S-c5Jb for ; Mon, 8 Feb 2016 05:04:10 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC641B2A87 for ; Mon, 8 Feb 2016 05:04:10 -0800 (PST) Received: by mail-qg0-x229.google.com with SMTP id y9so112151344qgd.3 for ; Mon, 08 Feb 2016 05:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=igHYFp4otrmKRID6XWcdEmYH75Vgn/KblfPtsKHT2ls=; b=iGe5G7ahyHHDcJNy77SiySvY3LbX7zVHP0OJQGtWGvWJP+e1/1gfeN9d27CfeHqqG4 OdsMeHEIzQ8SvK8y5KMMkEUf8EWkO8CUvAl6MKh++KAQouCm7ipWZQBpvJLha0DanF2X kySYQVeioUzeJwlqHbZ3KTFAclOzAWGvBjNIevE9qLSybUTEvsMcJomo6ZV8SamXKq0J 9YmPo+sBRnBx3Pt9YbapY668IQhIWWaL7LnGJq+fexF2SRwU29sOTcYyKUSFudCAs3Jl +xXCZDyID0lTP90WW6FRWxcIQe7oVSIAc7H76NBe5WY2pvS7k9J8nvKDmKLnkV0fxfgs 6K6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=igHYFp4otrmKRID6XWcdEmYH75Vgn/KblfPtsKHT2ls=; b=ICFo1U7Uxk37tqxtnh+0rKfHi5A4woxdYRvGYcndPHIeejM2WIOUCEyu0m4CMR4wCq A4aUzHl43H1CrnCI/EKzPr6qX7dyYaGUE1OPh3u0yTHw6B6SuL0cSH3PkwJNVLfImDFm r8Co6TClV6EwOYj6+omFOXh3UvbxTdn+L+tjb6sxb12t8THZcAb7PGqCNoTjhcXcgggQ Kuij8Yi6T3noc2EjqQM8U+KzKoUlQIMHlnr1phzdnFJ+TZim8H5ZD3M2jGSw+Hm5Kk5p jKrwSTOK69+tMupmj2L2GOzmD05WIf5oDYKXzO8XNN2f8tG+HXKGXx0+0Koa7ZLKQvWt qdGA== X-Gm-Message-State: AG10YORi/DjB6knuAsL1Me2bZbfsaf3jfXUBczfuaYRm/nt0t+OwbZ+V4I8chhj//PRqRw== X-Received: by 10.140.176.19 with SMTP id w19mr35787446qhw.59.1454936649432; Mon, 08 Feb 2016 05:04:09 -0800 (PST) Received: from [192.168.1.68] ([191.115.87.228]) by smtp.gmail.com with ESMTPSA id 90sm13856539qgo.14.2016.02.08.05.04.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 08 Feb 2016 05:04:09 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_06A6EE46-A711-499F-8679-64691C2C75D8" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: <56B7CDED.7090203@mit.edu> Date: Mon, 8 Feb 2016 10:04:03 -0300 Message-Id: References: <569E265D.2080703@gmx.net> <56B5DC45.5080407@lodderstedt.net> <27468C38-9A52-4A3C-94BE-C37973739831@adm.umu.se> <56B7CDED.7090203@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: Stateless Client Identifier for OAuth 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 13:04:13 -0000 --Apple-Mail=_06A6EE46-A711-499F-8679-64691C2C75D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yes this is an example of how you could do it inside the existing specs. = =20 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 wrote: >=20 > There's already support for this, but just a quick reminder to the = working group that we already hint at this capability in RFC7951: >=20 > 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. >=20 > (Last paragraph of section 2.3) >=20 > -- Justin >=20 > On 2/7/2016 3:07 PM, Roland Hedberg wrote: >> +1 >>=20 >>> 6 feb 2016 kl. 19:56 skrev William Denniss = : >>>=20 >>> +1 to adopt. >>>=20 >>> I don't think we're planning to use this, but it looks useful and = doesn't harm interoperability so I support it. >>>=20 >>> On Sat, Feb 6, 2016 at 3:43 AM, Torsten Lodderstedt = wrote: >>> +1 >>>=20 >>>=20 >>> Am 04.02.2016 um 17:37 schrieb John Bradley: >>> I support it. >>>=20 >>> I have always thought of this as informational. It is not the only = way to do it, and has no real interoperability impact. >>>=20 >>> John B. >>> On Feb 4, 2016, at 3:29 AM, Mike Jones = wrote: >>>=20 >>> I support adoption of this document by the working group as either = an experimental or information specification. >>>=20 >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Hannes Tschofenig >>> Sent: Tuesday, January 19, 2016 4:05 AM >>> To: oauth@ietf.org >>> Subject: [OAUTH-WG] Call for Adoption: Stateless Client Identifier = for OAuth 2 >>>=20 >>> Hi all, >>>=20 >>> 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 = >>>=20 >>> 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. >>>=20 >>> Ciao >>> Hannes & Derek >>>=20 >>>=20 >>> _______________________________________________ >>> 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 = >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >> =94Everybody should be quiet near a little stream and listen." >> >=46rom =92Open House for Butterflies=92 by Ruth Krauss >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_06A6EE46-A711-499F-8679-64691C2C75D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 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 <jricher@mit.edu> = wrote:

=20 =20
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

On 2/7/2016 3:07 PM, Roland Hedberg wrote:
+1


6 feb 2016 kl. 19:56 skrev William =
Denniss <wdenniss@google.com>:

+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 <torsten@lodderstedt.net> wrote:
+1


Am 04.02.2016 um 17:37 schrieb John Bradley:
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 <Michael.Jones@microsoft.co=
m> wrote:

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

                                -- Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] =
On Behalf Of Hannes Tschofenig
Sent: Tuesday, January 19, 2016 4:05 AM
To: oauth@ietf.org
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


_______________________________________________
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

_______________________________________________
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

=94Everybody should be quiet near a =
little stream and listen."
>=46rom =92Open House for Butterflies=92 by Ruth Krauss




_______________________________________________
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

= --Apple-Mail=_06A6EE46-A711-499F-8679-64691C2C75D8--