Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

Torsten Lodderstedt <torsten@lodderstedt.net> Fri, 10 January 2020 17:58 UTC

Return-Path: <torsten@lodderstedt.net>
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 D0DFC12087E for <oauth@ietfa.amsl.com>; Fri, 10 Jan 2020 09:58:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 lCT-ZFao4KqY for <oauth@ietfa.amsl.com>; Fri, 10 Jan 2020 09:58:55 -0800 (PST)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 CE4DF120A52 for <oauth@ietf.org>; Fri, 10 Jan 2020 09:58:54 -0800 (PST)
Received: by mail-wr1-x432.google.com with SMTP id d16so2640188wre.10 for <oauth@ietf.org>; Fri, 10 Jan 2020 09:58:54 -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=qImPjs2ig4dwppPO0emAANLysn8e6KWfXF6GmaCEj1o=; b=fJ+1ZUr6Q0p+rHIH9VpAA/J3jLyJw5D23OiGorJmxR16Ojke0IMqJzp9njsynfKvwd n/h+laFD4zEtTYXzcITzsMfZEeX6ffLwMjYRJaBEiGnyTZyoehQa9JXktBpT6Di3zQrE MMXuzcJYkfUV0c4Czy2XXN5DYvHTjFr26xEK5bq9xiRVl9Pd0Vob56NXw6X45af0IinC j5RL2hvWbqYXAXfkz4IMm4LKxN3QCme0L+djaTgolmtCu7fO+EHHnOrvf9gzLTb6jNcB OmKipYepmdqyJ3Q6uO3xolFR8cnYJylEiE35MfZBRFeOt/Tt+MdJBvMm1uck6a/Ev6eD JPQQ==
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=qImPjs2ig4dwppPO0emAANLysn8e6KWfXF6GmaCEj1o=; b=A0rraQ3AkUqe65mizonuoJE3hvjOVnxL2LMOGvYEZIwizLB8lEFI4Ka0DZ9WRdPm1y Kkl9DW4D1MJ6Yrek57f+8/Jkroj37rHKfbAD5MYpUx44xqT63QssPMoc0Zyz9/IBcy+D ER3O1N9g0Fh4ZMZnTnA6lhOo7lYLiwGlhw0OqlFxPeONxRw+Z/QXoY6UYIlqoTpSpwSg b1Qtr1dIRGbzeRSA2DQDhNglYhbfF7ljRE3IGa62sxHgSAxa24f4xeTfssMrYCe1pqqJ ZGvez2ThO5hceTUtExNXCEEL09Tlf4xa0XmeV3BZXmIkpdCYaR9FraZgZvjfekcKkRLm cyrg==
X-Gm-Message-State: APjAAAVi5UQsFpTiW1SPX6WVA4lSWAUTmXq8NhPWrWQZ7PUTqv4w8YCN qyRV/NYmwdZ6LbvkKv7oChL1FA==
X-Google-Smtp-Source: APXvYqybW/nT91zBpelZypQjlqbMS+l3FpmrGmL7sx0iKWij/eQWDPgETK27tH34MFg8nQFDGiaGug==
X-Received: by 2002:adf:9144:: with SMTP id j62mr4564585wrj.168.1578679133287; Fri, 10 Jan 2020 09:58:53 -0800 (PST)
Received: from [10.30.1.34] ([213.151.95.78]) by smtp.gmail.com with ESMTPSA id h66sm3217355wme.41.2020.01.10.09.58.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jan 2020 09:58:52 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Mime-Version: 1.0 (1.0)
Date: Fri, 10 Jan 2020 18:58:51 +0100
Message-Id: <5747AA1C-0732-49F3-B18F-EF6395C405C9@lodderstedt.net>
References: <CAD9ie-tNugk-Whm4JrYD2vbZBGmrtUVNrqTeag_JsAm36qr1sw@mail.gmail.com>
Cc: Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>, "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
In-Reply-To: <CAD9ie-tNugk-Whm4JrYD2vbZBGmrtUVNrqTeag_JsAm36qr1sw@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
X-Mailer: iPad Mail (17C54)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/qeaMTRBvyf0xeeHib4DZNm_vg3Y>
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 <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jan 2020 17:58:57 -0000


> 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 Provider, 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, but design future extensions so that an implementation can separate duties if desired.

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

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

OAuth 3.0 could explicitely be developed with different architectures in mind.