Re: [Txauth] TxAuth Charter (Take 3.5)

Small suggestion: s/porting/migrating/

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 porting *migrating* from OAuth 2.0 and OpenID
Connect to the new protocol where possible.

On Tue, Jan 21, 2020 at 10:47 AM Justin Richer <jricher@mit.edu> wrote:

> Thanks, both of those nits make sense and we’ll be sure to incorporate
> them.
>
>  — Justin
>
> > On Jan 21, 2020, at 5:56 AM, Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
> >
> > another NIT: Approval of “access to” multiple resources and APIs in a
> single interaction
> >
> >> On 20. Jan 2020, at 19:05, Richard Backman, Annabelle <richanna=
> 40amazon.com@dmarc.ietf.org> wrote:
> >>
> >> NIT: Mixed verb tenses in the last sentence of paragraph 2. Replace “as
> well as providing” with “and provides”.
> >>
> >> –
> >> Annabelle Richard Backman
> >> AWS Identity
> >>
> >>
> >> From: Txauth <txauth-bounces@ietf.org> on behalf of Justin Richer <
> jricher@mit.edu>
> >> Date: Saturday, January 18, 2020 at 6:16 AM
> >> To: "txauth@ietf.org" <txauth@ietf.org>
> >> Subject: [Txauth] TxAuth Charter (Take 3.5)
> >>
> >> Thanks for all the feedback and discussion on the last round of the
> charter. I’ve made a few tweaks to it based on the conversations on this
> list, and a couple off-list, and have incorporated them here.
> >>
> >>>
> >>> This group is chartered to develop a 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. The use cases supported by this protocol will include
> widely deployed use cases currently supported by OAuth 2.0 and OpenID
> Connect (an extension of OAuth 2.0) as well as new use cases not enabled by
> OAuth 2.0.
> >>>
> >>> 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 the
> authorizing party as necessary through interaction mechanisms indicated by
> the protocol. This decoupling avoids many of the security concerns and
> technical challenges of OAuth 2.0 as well as providing 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 multiple resources and APIs in a single interaction
> >>> - Separation between the party authorizing access and the party
> operating the client requesting access
> >>> - Web, mobile, single-page, interaction-constrained, and other types
> of client 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 providing user, software, organization, and other
> pieces of information used in authorization decisions
> >>> - Token presentation mechanisms and key bindings
> >>> - Optimization of information and API access beyond identity 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
> >>> - 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 porting from OAuth 2.0 and OpenID Connect to the new
> protocol where possible.
> >>>
> >>> While the initial work will focus on using HTTP for communication
> between the client and the authorization server, the working group will
> seek to take advantage of optimization features of HTTP2 and HTTP3 where
> possible, and will strive to enable simple mapping to other protocols such
> as COAP.
> >>
> >> I would really appreciate the security AD’s weighing in at this stage.
> Thanks again everyone!
> >>
> >> — Justin
> >> --
> >> 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
>