Re: [OAUTH-WG] can a resource server provide indications about expected access tokens?
David Waite <david@alkaline-solutions.com> Sat, 11 December 2021 15:02 UTC
Return-Path: <david@alkaline-solutions.com>
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 7A4C03A08C5 for <oauth@ietfa.amsl.com>; Sat, 11 Dec 2021 07:02:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alkaline-solutions.com
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 g7w5x4D6WRHq for <oauth@ietfa.amsl.com>; Sat, 11 Dec 2021 07:02:24 -0800 (PST)
Received: from caesium6.alkaline.solutions (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B1D3A08C7 for <oauth@ietf.org>; Sat, 11 Dec 2021 07:02:24 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by caesium6.alkaline.solutions (Postfix) with ESMTPA id DCB5C2066C4; Sat, 11 Dec 2021 15:02:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1639234943; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5xhKhWaysLYEwqH3Z6gDLsc6yydWoEwuwfTQRa2IPj0=; b=aYdesUO4n6jAbUra+akK8fxk1JHFr0QLc3ePeie2my1y8z0ARAKkRlpLK+PylbLyRkrViK kfnzepFw7t42/ye53J1HGmgwJwfgzfpV+UIQuAsTRP4cek1lgMqylfOOYuAUKt2GsHEPgU RPSB7Zx3RekI+spTvc0VJz7Z7eSbfH0=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
From: David Waite <david@alkaline-solutions.com>
In-Reply-To: <CE063C3C-6992-4450-8153-0778C143C7A5@aueb.gr>
Date: Sat, 11 Dec 2021 08:02:20 -0700
Cc: oauth <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BE8254EF-9455-4D0A-A57A-9717C1BABDB9@alkaline-solutions.com>
References: <CE063C3C-6992-4450-8153-0778C143C7A5@aueb.gr>
To: Nikos Fotiou <fotiou@aueb.gr>
Authentication-Results: caesium6.alkaline.solutions; auth=pass smtp.mailfrom=david@alkaline-solutions.com
X-Spamd-Bar: +
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/bHFxfbwAacb_eLxf7fGEKqTpC0Y>
Subject: Re: [OAUTH-WG] can a resource server provide indications about expected access tokens?
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: Sat, 11 Dec 2021 15:02:30 -0000
> On Dec 11, 2021, at 3:35 AM, Nikos Fotiou <fotiou@aueb.gr> wrote: > > Hi, > > I have a use case where a resource server is protected and can only be accessed if a JWT is presented. Is there any way for the server to "indicate" the "expected" format of the JWT. For example, respond to unauthorized requests with something that would be translated into "I expect tokens form iss X with claims [A,B,C]" Normally, the scope of the token is part of the contract between the resource server and client (what sort of authorization is needed for the resource server), but other aspects of the relationship - such as format, or required information, or additional verification steps the user needs to take - are part of the contract between the AS and resource server. The ways to work with indicating that these requirements exist at token issuance include: 1. Scopes - wrap requirements up into scopes, such as having an “admin” scope require additional user authentication, or a “purchasing” scope require the user’s shipping address be embedded as a claim 2. Resources - require the client to use the `resource` parameter to indicate which resource server the token is meant for, and use AS policy to say which RSs get what sort of tokens or have what sort of issuance policy. -DW
- [OAUTH-WG] can a resource server provide indicati… Nikos Fotiou
- Re: [OAUTH-WG] can a resource server provide indi… Vladimir Dzhuvinov
- Re: [OAUTH-WG] can a resource server provide indi… Nikos Fotiou
- Re: [OAUTH-WG] can a resource server provide indi… Warren Parad
- Re: [OAUTH-WG] can a resource server provide indi… David Waite
- Re: [OAUTH-WG] can a resource server provide indi… Justin Richer