Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
Dick Hardt <dick.hardt@gmail.com> Mon, 06 July 2020 16:26 UTC
Return-Path: <dick.hardt@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B41F3A16CE; Mon, 6 Jul 2020 09:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 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, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Oy_bLmyfoQ69; Mon, 6 Jul 2020 09:26:19 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 DB77F3A16C1; Mon, 6 Jul 2020 09:26:18 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id 9so46098566ljv.5; Mon, 06 Jul 2020 09:26:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iOcRBA3CcD/B9Jju9GHisQZGgufIWcNJM8MUVh5EXSA=; b=jjJKSV0wGjyftmqgzB9jpGJg40QWqxt2KGGtgaFxbMjgl8NBfWWqgAGUIE42inywIl g8MJQzWJrta74Hx8lpZ6R7vRpot2dcxWiSzCLT0GmcGBC2q5iKJ5HwMA0HUbnoKBWnFy fgpWtP5p7jHAt1t7pFxpc7FnFInZdMqTbZTTgAB7RbJPCb7ZGoU3Rs9NF11nI6rGcvXt /rkSYkA/aMRI61tlllU3NnLfSzfjKH60wIpCOZ3UkOEoqShGG0dkKLeqV6G7tOAxqTME /uOvXVNbD7lHqG5SUceKzQ7vL+oS7Ud1MkFdNLYaksXCj0Bme1Zv9UyCVW7RnPgPBz6V teVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iOcRBA3CcD/B9Jju9GHisQZGgufIWcNJM8MUVh5EXSA=; b=adOwOsfmJpbeKrzfCsFtLLXGJjWFydObXjCx9PuY83fbqnSfDVA1mNyxXvTbt7vSiM jt2C2oSo57QOJPLwW7qk5tVhrJq0/jGuhAMFkTtdjfy9Te2T5ugt3ijlveIFPdoFvK9z xwTQl0o3EKL/28KB7cCugUDoxxZEnaFlcKXBMi7T5/jJXjc/mRivleJzZsaNaFcw0I+J OD2lB3gX7hukjsj3A9TK6xbv9U2SZAbUdwoTwMRhu9Pr5MtoLOnOZWC7EcgpwS6k+YUO /R/c+rgvL6d1dmTb3ytEKG2VgbCX+6CeWGHvy00ZZjQGF89F46apJk3LyAW5QBhWk8aS F6+Q==
X-Gm-Message-State: AOAM5328NdRmCAVytN7JWncR2a+hXHvabCEI8oZlD5dh7RdCSVk4BMeC Nwqu6msrsKmR8lEOu9Ke8T37MElETx0SSQsU61g=
X-Google-Smtp-Source: ABdhPJzRr7ezZ1qRqfRaXM8zD+a9GAFTFobd9fSARnWy4Ymf3U2wgUXyEmUKpJUj3vXxYNW6nqLKnQ75sJYaq5NOMl4=
X-Received: by 2002:a2e:b70b:: with SMTP id j11mr13990950ljo.142.1594052776969; Mon, 06 Jul 2020 09:26:16 -0700 (PDT)
MIME-Version: 1.0
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <CAD9ie-voeZUSaYVwWHHTN8ocsHq6OCReiOLOixxqOZ2qO3aOSw@mail.gmail.com> <830A4653-5912-46DE-8173-BA149899FDD3@mit.edu> <CAK2Cwb7KNHr1pEaeK=5iGZW6ij8YAtFt2khFiFOf1FfUaG9QtQ@mail.gmail.com> <e1a8197a96a24e229ed1ec956394337a@cert.org>
In-Reply-To: <e1a8197a96a24e229ed1ec956394337a@cert.org>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Mon, 06 Jul 2020 09:25:40 -0700
Message-ID: <CAD9ie-uH7nv15dPLd79DV4y16zcU=Thcfx0YMV3eYge6rjdn2A@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: Tom Jones <thomasclinganjones@gmail.com>, Justin Richer <jricher@mit.edu>, The IESG <iesg@ietf.org>, "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/related; boundary="00000000000087152805a9c8555b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/i7BMYplTbP5TU_t61YhENV_vpLw>
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jul 2020 16:26:23 -0000
Thanks Roman! On Mon, Jul 6, 2020 at 5:45 AM Roman Danyliw <rdd@cert.org> wrote: > Hi! > > > > The milestones below the charter text now reflect the proposed > simplification described below (by Dick). > > > > Regards, > > Roman > > > > *From:* iesg <iesg-bounces@ietf.org> *On Behalf Of * Tom Jones > *Sent:* Friday, June 26, 2020 6:10 PM > *To:* Justin Richer <jricher@mit.edu> > *Cc:* Dick Hardt <dick.hardt@gmail.com>; The IESG <iesg@ietf.org>; > txauth@ietf.org > *Subject:* Re: [Txauth] WG Review: Grant Negotiation and Authorization > Protocol (gnap) > > > > Right - I have already proposed binding to application level keys in other > venues and strongly oppose continued use of channel binding. > > Peace ..tom > > > > > > On Fri, Jun 26, 2020 at 2:03 PM Justin Richer <jricher@mit.edu> wrote: > > I agree with this proposed change in wording for the milestones. We don’t > want to artificially limit the key binding presentation mechanisms. While I > think the three listed are likely to be among the first ones we see (based > on prior art and current community interest), I don’t think we can predict > entirely what will be developed by the group and when. > > > > — Justin > > > > On Jun 26, 2020, at 1:21 PM, Dick Hardt <dick.hardt@gmail.com> wrote: > > > > > > I am concerned with the following milestones: > > > > > > Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, > to > WGLC > > Oct 2021 - Key presentation mechanism binding to the core protocol, > detached HTTP signatures, to WGLC > > Oct 2021 - Key presentation mechanism binding to the core protocol, > embedded HTTP signature, to WGLC > > > > I think it is overly prescriptive to specify which key presentation > mechanisms will be created, and it implies that other key presentation > mechanisms will not be worked on. While it is possible that channel binding > mechanisms such as TLS, detached HTTP signatures, and embedded HTTP > signatures will be appropriate key presentation mechanisms for GNAP, it is > also quite possible that the WG will determine one or more are not > appropriate, or the underlying mechanism may not gain acceptance, or > channel binding is not always needed. For example, the effort to bind OAuth > access tokens using RFC8471 was disbanded. > > > > Additionally, there are two primary communication channels in the protocol > that have different security requirements. The client to authorization > server, and the client to resource server. The term "core protocol" is > vague and could be construed that the same mechanism MUST be used in both > channels. > > > > I propose the following new wording: > > > > Oct 2021 - Key presentation mechanism binding for each communication > channel to WGLC. > > > > > > ---------- Forwarded message --------- > > From: *The IESG* <iesg-secretary@ietf.org> > Date: Fri, Jun 26, 2020 at 9:10 AM > Subject: WG Review: Grant Negotiation and Authorization Protocol (gnap) > To: IETF-Announce <ietf-announce@ietf.org> > Cc: <txauth@ietf.org> > > > > A new IETF WG has been proposed in the Security Area. The IESG has not made > any determination yet. The following draft charter was submitted, and is > provided for informational purposes only. Please send your comments to the > IESG mailing list (iesg@ietf.org) by 2020-07-06. > > Grant Negotiation and Authorization Protocol (gnap) > ----------------------------------------------------------------------- > Current status: Proposed WG > > Chairs: > Yaron Sheffer <yaronf.ietf@gmail.com> > Leif Johansson <leifj@sunet.se> > > Assigned Area Director: > Roman Danyliw <rdd@cert.org> > > Security Area Directors: > Benjamin Kaduk <kaduk@mit.edu> > Roman Danyliw <rdd@cert.org> > > Mailing list: > Address: txauth@ietf.org > To subscribe: https://www.ietf.org/mailman/listinfo/txauth > Archive: https://mailarchive.ietf.org/arch/browse/txauth/ > > Group page: https://datatracker.ietf.org/group/gnap/ > > Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/ > > This group is chartered to develop a fine-grained delegation protocol for > authorization and API access, as well as requesting and providing user > identifiers and claims. This protocol will allow an authorizing party to > delegate access to client software through an authorization server. It will > expand upon the uses cases currently supported by OAuth 2.0 and OpenID > Connect > (itself an extension of OAuth 2.0) to support authorizations scoped as > narrowly as a single transaction, provide a clear framework for interaction > among all parties involved in the protocol flow, and remove unnecessary > dependence on a browser or user-agent for coordinating interactions.. > > The delegation process will be acted upon by multiple parties in the > protocol, > each performing a specific role. The protocol will decouple the interaction > channels, such as the end user’s browser, from the delegation channel, > which > happens directly between the client and the authorization server (in > contrast > with OAuth 2.0, which is initiated by the client redirecting the user’s > browser). The protocol will include a means of specifying how the user can > potentially be involved in an interactive fashion during the delegation > process. The client and Authorization Server (AS) will use these > interaction > mechanisms to involve the user, as necessary, to make authorization > decisions. > This decoupling avoids many of the security concerns and technical > challenges > of OAuth 2.0 and provides a non-invasive path for supporting future types > of > clients and interaction channels. > > The group will define interoperability for this protocol between different > parties, including > - client and authorization server; > - client and resource server; and > - authorization server and resource server. > > The group will seek to minimize assumptions about the form of client > applications, allowing for: > - Fine-grained specification of access > - Approval of AS attestation to identifiers and other identity claims > - Approval of access to multiple resources and APIs in a single interaction > - Support for multiple access tokens in a single request and response > - Support for directed, audience-restricted access tokens > - Separation between the party authorizing access and the party operating > the > client requesting access > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > - Cryptographic agility for keys, message signatures, and proof of > possession > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other > information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding resource > requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information (including identifiers and > identity assertions) through the delegation process > > Additionally, the group will provide mechanisms for management of the > protocol > lifecycle including: > > - Discovery of the authorization server > - Revocation of active tokens > - Mechanisms for the AS and RS to communicate the access granted by an > access > token > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt > to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol > where possible. > > This group is not chartered to develop extensions to OAuth 2.0, and as such > will focus on new technological solutions not necessarily compatible with > OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be directed > to the OAuth Working Group, including functionality back-ported from the > protocol developed here to OAuth 2.0. > > The group is chartered to develop mechanisms for applying cryptographic > methods, such as JOSE and COSE, to the delegation process. This group is > not > chartered to develop new cryptographic methods. > > The group is chartered to develop mechanisms for conveying identity > information within the protocol including existing identifiers (such as > email > addresses, phone numbers, usernames, and subject identifiers) and > assertions > (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable > Credentials). The group is not chartered to develop new formats for > identifiers or assertions, nor is the group chartered to develop schemas > for > user information, profiles, or other identity attributes, unless a viable > existing format is not available. > > The initial work will focus on using HTTPS for communication between the > client and the authorization server, taking advantage of optimization > features of HTTP/2 and HTTP/3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol including TLS, > detached HTTP signature, and embedded HTTP signatures > - Conveyance mechanisms for identifiers and assertions > - Guidelines for use of protocol extension points > - (if needed) Guidelines on migration paths, implementation, and operations > > Where possible, the group will seek to make use of tools to guide and > inform > the standardization process including formal analysis, architecture > documents, > and use case documents. These artifacts will not be considered as working > group milestones or deliverables. > > The working group will cooperate and coordinate with other IETF WGs such as > OAUTH, and work with external organizations, such as the OpenID Foundation, > as appropriate. > > Milestones: > > Jul 2021 - Core delegation protocol in WGLC > > Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, > to > WGLC > > Oct 2021 - Key presentation mechanism binding to the core protocol, > detached HTTP signatures, to WGLC > > Oct 2021 - Key presentation mechanism binding to the core protocol, > embedded HTTP signature, to WGLC > > Dec 2021 - Guidelines for use of protocol extension points to WGLC > > Feb 2022 - Guidelines on migration paths, implementation, and operations > to > WGLC > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > > [image: Image removed by sender.]ᐧ > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > >
- [Txauth] WG Review: Grant Negotiation and Authori… The IESG
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Justin Richer
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Tom Jones
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Justin Richer
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Tom Jones
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Justin Richer
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Justin Richer
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Mike Varley
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Tom Jones
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Roman Danyliw
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Roman Danyliw
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Roman Danyliw
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Tom Jones
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Tom Jones
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Justin Richer
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Tom Jones
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Justin Richer