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

[Amanjeev Sethi <[e-mail]>]

Hello Everyone,

I am relatively new here and in fact only been reading OIDC spec for past 6-8 months. I am still trying to grasp the TxAuth by watching Justin's talks and posts. I am here to mostly see and hopefully participate in some corners of this spec. 


> 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


On Fri, Mar 6, 2020, at 11:44 AM, Yaron Sheffer 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
>