Re: [Txauth] alternative charter writeup

+1

On Sat, Jan 11, 2020 at 04:56 Dick Hardt <dick.hardt@gmail.com> wrote:

> 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 <jricher@mit.edu> 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 <dick.hardt@gmail.com> 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
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
-- 
Sent from a mobile device, please excuse any typos