Re: [Txauth] Call for charter consensus - TxAuth WG

[Matthew De Haast <[e-mail]>]

>
> 1.  Do you support the charter text provided at the end of this email?
>

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

Matt

On Fri, Mar 6, 2020 at 6:45 PM Yaron Sheffer <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>