Re: [OAUTH-WG] RAR WGLC comment

Torsten Lodderstedt <torsten@lodderstedt.net> Sat, 19 June 2021 13:36 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 9103A3A0FF7 for <oauth@ietfa.amsl.com>; Sat, 19 Jun 2021 06:36:27 -0700 (PDT)
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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 o4Akt7pa2k-i for <oauth@ietfa.amsl.com>; Sat, 19 Jun 2021 06:36:22 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 40A793A0FF5 for <oauth@ietf.org>; Sat, 19 Jun 2021 06:36:22 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id s6so12421982edu.10 for <oauth@ietf.org>; Sat, 19 Jun 2021 06:36:22 -0700 (PDT)
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=6ihmlzLvhMBcaM/Ge7I+BYn/hlP8gnmYGGVdcxwJwM0=; b=PJ2g72mYcWxF1AY3ejs6Ba25ADiab8VwathJUhTtT6QW16SUuk8eDGzNODwLa4rM0T w0z3i90swhdM8ln96kBFYCByMIEYthKcza49rjNHnFek5xt5WAV2YVdehXKvi80V2UWH VyMwqmZbVQaBgzTfXIo8+Ri5kCJxmb2QFQBEhvuqZM4drT+zEdJHC4yH0isYv55y6uNo TDxQnHbWbNsXEeLNuA/vVPPv3p3g6ubolzjrUcK/DDS6vnvHjV4gouFHUv5LdyTI3olA SLSR6DWLlqWpIyRAtMWO6LWwqMa8UvfMWxsAlzPVGJjgUtx4ol+ct/W2t87i94O2w2Ws nPeQ==
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=6ihmlzLvhMBcaM/Ge7I+BYn/hlP8gnmYGGVdcxwJwM0=; b=nMenFKBzyoOO30gK9CwRB3a0DdQxpLaBcPMWriZA1VAihJ1zoGMnCRxpkz1hTYKguw KvJ6cP45Z5PqSNote08HOXqoEK2DBnoRasu/YxpsnVUoPrxbx6cBwAMCxJuXx7HHPUGl Mk7hXq9jrxUpyqIYxutkjKn9Ggd0hmaVNP+Bxt/UIsptC6oE3a9HV10IRlVRPSGTMtKS gWn24LpUixFjqkBhYr4AKzMFHHVjGa6JZ487QKQn/9xzMQ+KkIHzL/lnpWlL+o4ftOut bZcluFsnZvvVGnmts0mpNdaCaeoPosA3UmQ//3LzbKluHw3ECXCDBqfsEwv8siruNtDV uHuw==
X-Gm-Message-State: AOAM530jQwr1uFPVf0zVLGPj0ih6bC3ACGuT20tv4gRd2jrEFB158EKg k3vEN406U/erZLRZ92eolgWV+QTE4pCUmA==
X-Google-Smtp-Source: ABdhPJwF1YbNE8j6Ed45ymKJNqCazgAx42JQawRVMyaINDAxYLK5ey63KuccvFXdUiVwlv6Fp34YSw==
X-Received: by 2002:a05:6402:543:: with SMTP id i3mr10894260edx.173.1624109779469; Sat, 19 Jun 2021 06:36:19 -0700 (PDT)
Received: from smtpclient.apple (p200300eb8f0dc7e7c9e5c8a858db0974.dip0.t-ipconnect.de. [2003:eb:8f0d:c7e7:c9e5:c8a8:58db:974]) by smtp.gmail.com with ESMTPSA id w2sm2344829ejn.118.2021.06.19.06.36.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 19 Jun 2021 06:36:19 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-AF254CED-874B-4718-B861-6B3123A3115D"
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Mime-Version: 1.0 (1.0)
Date: Sat, 19 Jun 2021 15:36:18 +0200
Message-Id: <F4877542-CD79-4401-B8F4-A06C321959C0@lodderstedt.net>
References: <CA+k3eCR-CABXDt5CFH6q4vG-hVZ-pRGyO0zm0jGPF7SVfEO7Fw@mail.gmail.com>
Cc: oauth <oauth@ietf.org>
In-Reply-To: <CA+k3eCR-CABXDt5CFH6q4vG-hVZ-pRGyO0zm0jGPF7SVfEO7Fw@mail.gmail.com>
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (18F72)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/L2VEZVDILeAGgYo6Qipd0BGsj3E>
Subject: Re: [OAUTH-WG] RAR WGLC comment
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, 19 Jun 2021 13:36:28 -0000

Hi Brian,

the idea was to use resource indicators as convenient short cut to support audience restricted access tokens. However, I agree this can be achieved by specifying authorization details in the token request as well.

So I‘m fine with dropping resource indicators for RAR at all. This means RAR on one hand and scopes + resource indicators on the other hand are clearly decoupled and independent.

best regards,
Torsten.

> Am 18.06.2021 um 20:13 schrieb Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>:
> 
> 
> In my reading and understanding of the text and intent, the content and meaning of a particular authorization details object are fully governed by its "type". And while the draft provides a set of common data elements intended to be usable across different types (locations, actions, datatypes, identifier, privileges) a specific type is free to define whatever suits its needs. A type definition may or may not involve those common elements and could even use the same name(s) with different meaning or structure. 
> 
> So, while I understand the motivation behind the RFC8707 resource parameter being usable in a token request to make the AS filter, the included authorization details of the resultant token based on the "locations" element[1], I'm a bit concerned about a layering problem here. The authorization details objects of the grant might not contain a "locations" element or might have one with a different meaning or structure.  
> 
> The draft also describes using the authorization_details token request parameter to specify the authorization details a client wants the AS to assign to a particular access token[2]. So the problematic resource parameter behaviour is also kind of redundant. I think maybe it should be removed.
> 
> [*] described in https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-6.2 and mentioned at https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-1-8 and in https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-7-1
> 
> [2] https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#name-token-request
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1624644831000000&usg=AOvVaw1Ol8hiDotFufYe9jQCTi1m