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

[David Skaife <[e-mail]>]

Hi,

I'm fairly new to this group (and the OAuth group) but I'm hoping to
participate and help here.

> 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. I share some of the same concerns that Torsten has highlighted, but
overall I'm happy with the charter text. I like that it explicitly states
that we're aiming to create a *protocol*, not a *framework *(like OAuth 2.0
was).

>
> 2.  Are you willing to author or participate in the development of the
drafts of this WG?

Yes, I will help as much as my time permits.

>
> 3.  Are you willing to help review the drafts of this WG?

Yes.

>
> 4.  Are you interested in implementing drafts of this WG?

Yes.


Many thanks,
David Skaife


On Sat, Mar 7, 2020 at 3:17 PM Torsten Lodderstedt <torsten=
[e-mail]> wrote:

> Hi,
>
> > Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <[e-mail]>:
> >
> > 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)?
>
> I‘m in although I have to admit I‘m slightly concerned the scope of the
> charter is too broad, e.g. identify alone is a huge topic.
>
> We need to keep an eye on this aspect in order to make sure, the group is
> able to work effectively and the specs we will be producing are as simple
> as possible and foster interoperability.
>
> >
> > 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
>
> best regards,
> Torsten.
>
> >
> > 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
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>