Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFA8120B3E for ; Fri, 10 Jan 2020 10:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net 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 XKhOZCBjWAZL for ; Fri, 10 Jan 2020 10:14:43 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 14226120B01 for ; Fri, 10 Jan 2020 10:14:43 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id z7so2668981wrl.13 for ; Fri, 10 Jan 2020 10:14:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=gnWxfchKmqfwcp0HhtX7N9oK7w6fRoWoKdvGsrj1DBQ=; b=morHIYDoEvkqmFOLmJDFnavmo9L2olSGIOUk9ZcBbYvLI6bzDih3vwHJDy9xvoxWn1 94jD6GutGh4s9VL333YwEtSzI2eCddm29525i9+MM1TAtGQ6KRUrLhqjdy7qyKBniqmu JvlL4l5xVfRKehQRjTSAPMCoHW7RT/oRVxfjj865/m0RX6iKZ8FCJShc8l5erKTTRbAL oKesku9UZ2SwKIN0gWJpLUXf0m5YVceBR3bPZgqF1hZoFq2XFEpXQPuZ8nhQef2jkTZn zz1bhXRcmgCGrC2JpXJ8eynKZqC+hbSBUuSPlgeTf48gIuqlUoxkKMEM9Jd4NMXF6YDL GZ6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=gnWxfchKmqfwcp0HhtX7N9oK7w6fRoWoKdvGsrj1DBQ=; b=BZ9cHBfTqUabxFT8olDvWo49Pr3kXCd+a4w8jgFN4txaCqGzSBqRn736TbmCxMBWym beQndKTxYs/UOEOaSk3XFM4RSOd8bcUITOEoQA7JX7Vgxet9TOnfHSq27cw4fJqDdxFv CX+bciH6iv8bRK6bEKX94SlaqNPpLtL0uDnnonO333rEC6C9GMsuzOG2vR6MEXjJxypT kH3raODoHrO3ROFPakzHPleeCZC4skFUpKA9FgwIcwLFCgboCcz/Wb4Hib0yJsRvvtZ/ sr2R59pOI2sIiTIDLgsbIcfFGVoT3mhAyAGl0fbVCsuUrthvbkTZ3N9er8Mt7kBBeg4s 8Z7A== X-Gm-Message-State: APjAAAUYr3XkXc6IYioRkxxQsbS9ZJ+YqZQnmw04Q6K76buu7uQEo41U IOGQb+1+d0cWitTBDDQFd+aCufbEBVJRHMIf X-Google-Smtp-Source: APXvYqxqsAtDv0/8CA+bthPQ+lUdmtw6Fy4ik4Uv56APZ4Di2PHWx8qLCO7BO0EqVV0isQ6yVhpc0A== X-Received: by 2002:a5d:49cc:: with SMTP id t12mr4591741wrs.363.1578680081512; Fri, 10 Jan 2020 10:14:41 -0800 (PST) Received: from [10.30.1.34] ([213.151.95.78]) by smtp.gmail.com with ESMTPSA id s8sm2955861wrt.57.2020.01.10.10.14.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jan 2020 10:14:40 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-1DAAC006-91BD-4DD0-92AE-01DD67862BA7 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Fri, 10 Jan 2020 19:14:39 +0100 Message-Id: <9D366169-C548-4D5C-8F4B-E546829DC9B0@lodderstedt.net> References: Cc: Justin Richer , oauth , "Richard Backman, Annabelle" , Mike Jones In-Reply-To: To: Dick Hardt X-Mailer: iPad Mail (17C54) Archived-At: Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 18:14:46 -0000 --Apple-Mail-1DAAC006-91BD-4DD0-92AE-01DD67862BA7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable You mean additional JWKS URIs, for example? > Am 10.01.2020 um 19:09 schrieb Dick Hardt : >=20 > =EF=BB=BF > Perhaps I am misunderstanding what Annabelle was getting at, but having mo= re than one key in the metadata document would solve the the issue. IE, exte= nsions would define their own key instead of using the same one. >=20 > The metadata document itself was an extension.=20 >=20 >=20 >> On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt wrote: >>=20 >>=20 >> > Am 10.01.2020 um 18:23 schrieb Dick Hardt : >> >=20 >> > As OAuth 2.0 has been extended, the AS is now also an OpenID Connect Pr= ovider, and the access token is being defined. These extensions have assumed= all of this functionality is a monolith.=20 >> >=20 >> > I'm not suggesting that we MUST make changes to existing extensions, bu= t design future extensions so that an implementation can separate duties if d= esired. >>=20 >> How do you envision this to work? As you said, OAuth 2.0 is built on the a= ssumption the AS is (at least logically) a monolith. All extension were buil= t on that underlying assumption. I don=E2=80=99t see how an arbitrary extens= ion can relax that assumption and still be compatible with the rest (just re= visit the discussion re PAR and keys). >>=20 >> I think we should accept this design assumption, in the same way we shoul= d accept form encoding as request format instead of JSON, for OAuth 2.0 exte= nsions.=20 >>=20 >> OAuth 3.0 could explicitely be developed with different architectures in m= ind. --Apple-Mail-1DAAC006-91BD-4DD0-92AE-01DD67862BA7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
You mean additional JWKS U= RIs, for example?

Am 10.= 01.2020 um 19:09 schrieb Dick Hardt <dick.hardt@gmail.com>:

=EF=BB=BF
Perhaps I am misunderstanding what Annabelle was getting at, but ha= ving more than one key in the metadata document would solve the the issue. I= E, extensions would define their own key instead of using the same one.
=
The metadata document itself was an extension. 


On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=
> Am 10.01.2020 um 18:23 schrieb Dick Hardt <dick.hardt@gmail.com>:
>
> As OAuth 2.0 has been extended, the AS is now also an OpenID Connect Pr= ovider, and the access token is being defined. These extensions have assumed= all of this functionality is a monolith.
>
> I'm not suggesting that we MUST make changes to existing extensions, bu= t design future extensions so that an implementation can separate duties if d= esired.

How do you envision this to work? As you said, OAuth 2.0 is built on the ass= umption the AS is (at least logically) a monolith. All extension were built o= n that underlying assumption. I don=E2=80=99t see how an arbitrary extension= can relax that assumption and still be compatible with the rest (just revis= it the discussion re PAR and keys).

I think we should accept this design assumption, in the same way we should a= ccept form encoding as request format instead of JSON, for OAuth 2.0 extensi= ons.

OAuth 3.0 could explicitely be developed with different architectures in min= d.
= --Apple-Mail-1DAAC006-91BD-4DD0-92AE-01DD67862BA7--