Re: [Txauth] alternative charter writeup

[Dick Hardt <[e-mail]>]

This looks even better! Thanks Justin.

What do others think of the proposed charter now?
ᐧ

On Fri, Jan 10, 2020 at 12:43 PM Justin Richer <[e-mail]> wrote:

> Thanks, Dick. I’ve been working on an updated charter based on everyone’s
> feedback, and I was aiming to have out today anyway, so this timing is
> helpful. So here’s my take on a new charter, incorporating some of your
> points below:
>
> This group is chartered to develop a delegation protocol for identity,
> authorization, 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.
>
> The delegation process will be acted upon by multiple parties in the
> protocol, each performing a specific role. The protocol will be initiated
> by the client interacting directly with the authorization server (in
> contrast with OAuth 2 which is initiated by the client redirecting the
> user’s browser). The client will involve the authorizing party as necessary
> through interaction mechanisms indicated by the protocol.
>
> Additionally, the delegation process will allow for:
>
> - Fine-grained specification of resource access
> - Approval of identity claims and multiple resources in a single
> interaction
> - Delegation between multiple users
> - Web, mobile, single-page, 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
>
> 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, and will strive
> to enable simple mapping to other protocols such as COAP.
>
> On Jan 10, 2020, at 12:04 PM, Dick Hardt <[e-mail]> wrote:
>
> Hey
>
> I've written an alternative charter that I hope captures some of the
> feedback on Justin's charter.
>
> I found it easier to rewrite the charter to broaden the marketplace of
> ideas.
>
> Key ideas:
>
> - This work supports existing OAuth 2.0, and OpenID Connect use cases.
>
> - The client interacts directly with the authorization server.
>
> /Dick
>
> ----
>
> This group is chartered to develop a delegated identity and authorization
> protocol. The use cases supported by this protocol will include widely
> deployed use cases currently supported by OAuth 2.0, and OpenID Connect. In
> contrast to OAuth 2.0 and OpenID Connect, where the protocol is initiated
> by redirecting the user's browser to an authorization server, this protocol
> will be initiated by the client directly interacting with the authorization
> server.
>
> Additionally, the protocol will allow:
> - fine-grained specification of resource access
> - the user to approve requests for identity claims and access to multiple
> resources in one interaction
> - web, mobile, single-page, and other client applications
> - taking advantage of optimization features in HTTP2 and HTTP3
>
> The group will define extension points for this protocol to allow for
> flexibility in areas including:
>
> - discovery of the authorization server
> - cryptographic agility for keys, message signatures, and proof of
> possession
> - user interaction mechanisms including web and non-web methods- token
> presentation mechanisms and key bindings
>
> Although the artifacts for this work are not intended or expected to be
> backwards-compatible with OAuth 2.0 or OpenID Connect, they will attempt to
> simplify porting from OAuth 2.0 and OpenID Connect, and strive to reuse
> existing semantics such as client identifiers, OAuth 2.0 scopes and access
> tokens, and OpenID Connect ID Tokens and claims.
>
> While the initial work will focus on using HTTP for communication between
> the client and the authorization server, the working group will strive to
> enable simple mapping to other protocols such as COAP.
>
>
> ᐧ
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>