Re: [Txauth] Call for charter consensus - TxAuth WG
Daniel DeGroff <daniel@fusionauth.io> Tue, 10 March 2020 03:49 UTC
Return-Path: <daniel@fusionauth.io>
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 5920B3A0EC5 for <txauth@ietfa.amsl.com>; Mon, 9 Mar 2020 20:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=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=fusionauth.io
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 vf60uyQAouBE for <txauth@ietfa.amsl.com>; Mon, 9 Mar 2020 20:49:37 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 487BA3A0ECE for <txauth@ietf.org>; Mon, 9 Mar 2020 20:49:27 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id u12so8303251ljo.2 for <txauth@ietf.org>; Mon, 09 Mar 2020 20:49:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fusionauth.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gjkJ9VIeoOLkyqleKI/7w9dCdhnrPMJ+hRx7Fw7n42U=; b=Bt3jRDsN+DDXpvhZkuvBEd9HdK5GJXuzln+h9NvTpxgGD8mEply7oAp942+fuX+MdA Bp6VVAmxMc8LmAzfzhjXopu2bQCnI6UdthstUKXoyh9suNCDLmUPhYml1A4ebpue3x55 emKZVQ4JDUf6A+rpzdP/4cPlKWSasPfN8n5mgKMe2ufBfH21f3mQ4wO0b8DbpE8SLUwt NHl2lMELfoUGq78+SsIsZq8B/JZKaaA0lRF13ngFViUd15qdimrgpn7M52o/A2McjoWJ GnpfQispW8gJ0pDpGj3E2kDZXIaaJZdNnUx1/Yo/XvRw27Pkm7aVUP+HBW6QDU2Rcp63 XSDA==
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=gjkJ9VIeoOLkyqleKI/7w9dCdhnrPMJ+hRx7Fw7n42U=; b=byTu/Y5T69z8Le/JjWT9VL1sNkz/dHOLWgNimEfSJTCpGOXRD5Vgjx4SAYT0Q6YMUb 9jjZAfI1M4ByJu5k5YXLQWyQKxX8n/p/AkpYcIGz523O+mNwqNGKJwRYIsydap+HwhxF yHN1g9cMqNDxSP8J1rxw9kswi/BBmU9LSkHy69L/8qzT2C0uma0kwwgNyPeazokmGvUH ZMgZR834JpHYb5Cmus7bPc0k3R0fqVz4fDaWjha9JVa1q8HtPIq7Gcxaput//d/rZsz4 WGC1YSzBo85cOSBKj+zz4AX2tOP3FmQqa5mOsNYnjSyhV9kWhPvhJTGaUDToD/JtDJsC wbOQ==
X-Gm-Message-State: ANhLgQ0dmpR69CpQWYIRfnc2tSfNAkRKODFECNOskaHg2GsGuU1DfEwT j3H3g8x+urXYy6XRQTJ+i6qRV2Rj4aMB6riqR3LXzQ==
X-Google-Smtp-Source: ADFU+vtyyFfCrtqYLyWwbaD7qtvH9deGY2NvXoIrO/9eZ0mCRlcUXLPq7hbdNYSC1ysEAu4dJCAzh8uAoNUPvpF2HSo=
X-Received: by 2002:a2e:a419:: with SMTP id p25mr1504579ljn.206.1583812159918; Mon, 09 Mar 2020 20:49:19 -0700 (PDT)
MIME-Version: 1.0
References: <A01F5301-54DF-41D4-8ABE-8B070180F6FE@gmail.com>
In-Reply-To: <A01F5301-54DF-41D4-8ABE-8B070180F6FE@gmail.com>
From: Daniel DeGroff <daniel@fusionauth.io>
Date: Mon, 09 Mar 2020 21:49:08 -0600
Message-ID: <CAMJpJi8ECpgT5-fu4kgJ3NU1MbrkiiQ01+VdeMvAjO8wY-EPdA@mail.gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002ee8be05a07801f0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/wkrH2fhmqAyIChfS-uhsfUDCFbo>
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG
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: Tue, 10 Mar 2020 03:49:45 -0000
Hi, > 1. Do you support the charter text provided at the end of this email? Or do you have major objections, blocking concerns or feedback (if so please elaborate)? Yes > 2. Are you willing to author or participate in the development of the drafts of this WG? Yes > 3. Are you willing to help review the drafts of this WG? Yes > 4. Are you interested in implementing drafts of this WG? Yes Daniel daniel@fusionauth.io On Fri, Mar 6, 2020 at 9:45 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote: > Hi Everyone, > > It appears that momentum is forming around the proposed formation of a > TxAuth working group. We’d like to more formally gauge interest in > proceeding with this work. Please do so by responding to the following > questions: > > 1. Do you support the charter text provided at the end of this email? Or > do you have major objections, blocking concerns or feedback (if so please > elaborate)? > > 2. Are you willing to author or participate in the development of the > drafts of this WG? > > 3. Are you willing to help review the drafts of this WG? > > 4. Are you interested in implementing drafts of this WG? > > The call will run for two weeks, until March 21. If you think that the > charter should be amended In a significant way, please reply on a separate > thread. > > The feedback provided here will help the IESG come to a decision on the > formation of a new WG. Given the constraints of the chartering process, > regardless of the outcome of this consensus call, we will be meeting in > Vancouver as a BoF. > > Thanks, > Yaron and Dick > > --- Charter Text Follows --- > > This group is chartered to develop a fine-grained delegation protocol for > authorization, identity, and API access. 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 client and AS will involve a user to > make an authorization decision as necessary through interaction mechanisms > indicated by the protocol. 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. > > Additionally, the delegation process will allow for: > > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single interaction > - Separation between the party authorizing access and the party operating > the client requesting access > - A variety of client applications, including Web, mobile, single-page, > and interaction-constrained applications > > 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 pieces > of 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 through the delegation > process (including identity) > > Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > > - Discovery of the authorization server > - Revocation of active tokens > - Query of token rights by resource servers > > 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 > developed in 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 initial work will focus on using HTTP for communication between the > client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 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 for TLS, > detached HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >
- [Txauth] Call for charter consensus - TxAuth WG Yaron Sheffer
- Re: [Txauth] Call for charter consensus - TxAuth … Aaron Parecki
- Re: [Txauth] Call for charter consensus - TxAuth … Aleksei Petrov
- Re: [Txauth] Call for charter consensus - TxAuth … Amanjeev Sethi
- Re: [Txauth] Call for charter consensus - TxAuth … Torsten Lodderstedt
- Re: [Txauth] Call for charter consensus - TxAuth … David Skaife
- Re: [Txauth] Call for charter consensus - TxAuth … Leif Johansson
- Re: [Txauth] Call for charter consensus - TxAuth … Florian Biesinger
- Re: [Txauth] Call for charter consensus - TxAuth … Lee McGovern
- Re: [Txauth] Call for charter consensus - TxAuth … Daniel DeGroff
- Re: [Txauth] Call for charter consensus - TxAuth … Justin Richer
- Re: [Txauth] Call for charter consensus - TxAuth … Sudipta Pal
- Re: [Txauth] Call for charter consensus - TxAuth … Dmitri Zagidulin
- Re: [Txauth] Call for charter consensus - TxAuth … Fabien Imbault
- Re: [Txauth] Call for charter consensus - TxAuth … Matthew De Haast
- Re: [Txauth] Call for charter consensus - TxAuth … Fabien Imbault
- Re: [Txauth] Call for charter consensus - TxAuth … Justin Richer
- Re: [Txauth] Call for charter consensus - TxAuth … Stephen Moore
- Re: [Txauth] Call for charter consensus - TxAuth … Tobias Looker
- Re: [Txauth] Call for charter consensus - TxAuth … Richard Backman, Annabelle
- Re: [Txauth] [EXTERNAL] Re: Call for charter cons… Mike Jones
- Re: [Txauth] [EXTERNAL] Re: Call for charter cons… Justin Richer
- Re: [Txauth] Call for charter consensus - TxAuth … Mike Jones
- Re: [Txauth] Call for charter consensus - TxAuth … Aaron Parecki
- Re: [Txauth] Call for charter consensus - TxAuth … Justin Richer
- Re: [Txauth] Call for charter consensus - TxAuth … Mike Jones
- Re: [Txauth] Call for charter consensus - TxAuth … David Skaife
- Re: [Txauth] Call for charter consensus - TxAuth … Justin Richer
- Re: [Txauth] Call for charter consensus - TxAuth … Torsten Lodderstedt
- Re: [Txauth] Call for charter consensus - TxAuth … Justin Richer
- Re: [Txauth] Call for charter consensus - TxAuth … Torsten Lodderstedt
- Re: [Txauth] Call for charter consensus - TxAuth … Justin Richer
- Re: [Txauth] Call for charter consensus - TxAuth … Torsten Lodderstedt
- Re: [Txauth] Call for charter consensus - TxAuth … Vladimir Dzhuvinov
- Re: [Txauth] Call for charter consensus - TxAuth … Torsten Lodderstedt
- Re: [Txauth] Call for charter consensus - TxAuth … Mike Jones
- Re: [Txauth] Call for charter consensus - TxAuth … Justin Richer
- Re: [Txauth] Call for charter consensus - TxAuth … Torsten Lodderstedt
- Re: [Txauth] Call for charter consensus - TxAuth … Justin Richer
- Re: [Txauth] Call for charter consensus - TxAuth … David Skaife
- Re: [Txauth] Call for charter consensus - TxAuth … Dick Hardt
- Re: [Txauth] Call for charter consensus - TxAuth … Nat Sakimura
- Re: [Txauth] Call for charter consensus - TxAuth … Vittorio Bertocci
- Re: [Txauth] Call for charter consensus - TxAuth … Vijay IETF
- Re: [Txauth] Call for charter consensus - TxAuth … Justin Richer
- Re: [Txauth] Call for charter consensus - TxAuth … Dick Hardt
- Re: [Txauth] Call for charter consensus - TxAuth … Mike Jones
- Re: [Txauth] Call for charter consensus - TxAuth … Dick Hardt
- Re: [Txauth] Call for charter consensus - TxAuth … Kim
- Re: [Txauth] Call for charter consensus - TxAuth … Brian Campbell
- Re: [Txauth] Call for charter consensus - TxAuth … Justin Richer
- Re: [Txauth] Call for charter consensus - TxAuth … Justin Richer
- Re: [Txauth] Call for charter consensus - TxAuth … Dick Hardt
- Re: [Txauth] Call for charter consensus - TxAuth … Torsten Lodderstedt
- Re: [Txauth] Call for charter consensus - TxAuth … Justin Richer
- Re: [Txauth] Call for charter consensus - TxAuth … Justin Richer
- Re: [Txauth] Call for charter consensus - TxAuth … Torsten Lodderstedt
- Re: [Txauth] Call for charter consensus - TxAuth … Justin Richer
- Re: [Txauth] Call for charter consensus - TxAuth … Torsten Lodderstedt
- Re: [Txauth] Call for charter consensus - TxAuth … Nat Sakimura
- Re: [Txauth] Call for charter consensus - TxAuth … Dick Hardt
- Re: [Txauth] Call for charter consensus - TxAuth … Justin Richer