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 3EF881A1A28 for ; Tue, 24 Feb 2015 16:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 RrBu0b-2Ixgb for ; Tue, 24 Feb 2015 16:28:59 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1991A0396 for ; Tue, 24 Feb 2015 16:28:59 -0800 (PST) Received: from DM2PR03CA0033.namprd03.prod.outlook.com (10.141.96.32) by DM2PR03MB397.namprd03.prod.outlook.com (10.141.84.139) with Microsoft SMTP Server (TLS) id 15.1.106.11; Wed, 25 Feb 2015 00:28:56 +0000 Received: from BN1BFFO11FD038.protection.gbl (2a01:111:f400:7c10::1:193) by DM2PR03CA0033.outlook.office365.com (2a01:111:e400:2428::32) with Microsoft SMTP Server (TLS) id 15.1.99.9 via Frontend Transport; Wed, 25 Feb 2015 00:28:56 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD038.mail.protection.outlook.com (10.58.144.101) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Wed, 25 Feb 2015 00:28:55 +0000 Received: from TK5EX14MBXC290.redmond.corp.microsoft.com ([169.254.1.42]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0224.003; Wed, 25 Feb 2015 00:28:25 +0000 From: Mike Jones To: Bill Burke , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Thread-Index: AQHQRk+KdTW6focrw0+qa3R3HLsnGpzsbP6AgAD/rACABoKlgIACl1OAgAAGGYCAAAZBAIAAI6aAgAAFmYCACcSKAIAACNkAgAAFfYCAAAgkAA== Date: Wed, 25 Feb 2015 00:28:24 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943A2265169@TK5EX14MBXC290.redmond.corp.microsoft.com> References: <54DC2CB1.8090400@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com> <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com> <54E4D2A5.5030705@gmx.net> <4E1F6AAD24975D4BA5B1680429673943A2264EC6@TK5EX14MBXC290.redmond.corp.microsoft.com> <54ED1047.2010408@redhat.com> In-Reply-To: <54ED1047.2010408@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; redhat.com; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(164054003)(479174004)(189002)(51704005)(24454002)(52604005)(199003)(13464003)(377454003)(62966003)(66066001)(55846006)(2501003)(2656002)(16601075003)(77156002)(87936001)(19580405001)(19580395003)(86612001)(46406003)(104016003)(6806004)(23726002)(97736003)(54356999)(85806002)(50986999)(76176999)(26826002)(46102003)(69596002)(33656002)(587094005)(106466001)(92566002)(106116001)(97756001)(81156004)(50466002)(2900100001)(86362001)(64706001)(47776003)(2920100001)(2950100001)(15395725005)(107886001)(93886004)(102836002)(15975445007)(230783001)(68736005)(117326003)(2690400003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR03MB397; H:mail.microsoft.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR03MB397; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005004); SRVR:DM2PR03MB397; BCL:0; PCL:0; RULEID:; SRVR:DM2PR03MB397; X-Forefront-PRVS: 049897979A X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2015 00:28:55.7455 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR03MB397 Archived-At: Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg 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: Wed, 25 Feb 2015 00:29:01 -0000 Not that I'm aware of. -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Bill Burke Sent: Tuesday, February 24, 2015 3:59 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Is there plans to derive from any other parts of openid connect and bring t= hem into IETF/OAuth? Thanks. On 2/24/2015 6:47 PM, Mike Jones wrote: > Thanks, Kathleen. This had been discussed on the OAuth list before,=20 > but just in case you or the IETF legal counsel weren't aware of it -=20 > the reason that it's OK to produce derivative works from OpenID specs,=20 > as draft-ietf-oauth-dyn-reg did, is that it's explicitly allowed by=20 > the OpenID Foundation. See this text at=20 > http://openid.net/specs/openid-connect-registration-1_0.html#Notices -=20 > the spec from which text was copied: > > The OpenID Foundation (OIDF) grants to any Contributor, developer,=20 > implementer, or other interested party a non-exclusive, royalty free,=20 > worldwide copyright license to reproduce, prepare derivative works=20 > from, distribute, perform and display, this Implementers Draft or=20 > Final Specification solely for the purposes of (i) developing=20 > specifications, and (ii) implementing Implementers Drafts and Final=20 > Specifications based on such documents, provided that attribution be=20 > made to the OIDF as the source of the material, but that such=20 > attribution does not indicate an endorsement by the OIDF. > > You could pass that on to the appropriate IETF legal counsel if=20 > they're not already aware of it. > > --=20 > Mike > > *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Kathleen=20 > Moriarty > *Sent:* Tuesday, February 24, 2015 3:08 PM > *To:* Hannes Tschofenig > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg > > Hello, > > Thanks for updating the draft. I just want to confirm that Hannes is=20 > okay with the updated definitions and updates the shepherd report to=20 > reflect that. > > This is getting held up a bit while we sort through copyright of text=20 > from UMA and OpenID. The text from UMA went into an IETF draft, so=20 > that should be the reference as it clears up any possible issues as=20 > they provided that text in an IETF draft. > > The chairs will be helping to sort out the requirements with OpenID,=20 > per our discussions the IETF trustees. I'm not sure how long this=20 > will take, but wanted to provide a status so no one thought this had=20 > been dropped. > > Thanks. > > On Wed, Feb 18, 2015 at 12:57 PM, Hannes Tschofenig=20 > > wrote: > > Hi Justin, Hi John, > > I believe that provisioning a client with a unique id (which is what a=20 > client id/client secret is) allows some form of linkability. While it=20 > may be possible to associate the client to a specific user I could=20 > very well imagine that the correlation between activities from a user=20 > and those from the client (particularly when the client is running on=20 > the user's device) is quite possible. > > Ciao > Hannes > > On 02/18/2015 06:37 PM, Justin Richer wrote: > > I'll incorporate this feedback into another draft, to be posted by=20 > the > end of the week. Thanks everyone! > > > > - Justin > > > >> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty >>=20 > > >> >> wrote: > >> > >> > >> > >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley >> >> wrote: > >> > >> snip > >>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty > >>> > >>> >> wrote: > >>> > >>> > The client_id *could* be short lived, but they usually > aren't. I don't see any particular logging or tracking concerns using=20 > a dynamic OAuth client above using any other piece of software, ever.=20 > As such, I don't think it requires special calling out here. > >>> > >>> > >>> Help me understand why there should not be text that shows this > >>> is not an issue or please propose some text. This is bound to > >>> come up in IESG reviews if not addressed up front. > >>> > >>> > >> > >> The client_id is used to communicate to the Authorization server > >> to get a code or refresh token. Those tokens uniquely identify > >> the user from a privacy perspective. > >> It is the access tokens that are sent to the RS and those can and > >> should be rotated, but the client)id is not sent to the RS in > >> OAuth as part of the spec. > >> > >> If you did rotate the client_id then the AS would track it across > >> rotations, so it wouldn't really achieve anything. > >> > >> One thing we don't do is allow the client to specify the > >> client_id, that could allow correlation of the client across > >> multiple AS and that might be a privacy issue, but we don't > allow it. > >> > >> > >> Thanks, John. It may be helpful to add in this explanation unless =20 > >> there is some reason not to? > >> > >> > >> John B. > >> > >> > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >>=20 > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > > Best regards, > > Kathleen > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth