Re: [Txauth] alternative charter writeup

[Dick Hardt <[e-mail]>]

Sounds good to me.

On Mon, Jan 13, 2020 at 6:24 PM Justin Richer <[e-mail]> wrote:

> I can get behind this kind of addition. I like Annabelle’s framing of it
> in terms of decoupling, and some explanation of why we’re doing it in
> relation to OAuth 2’s approach. One of the key things, to me, is that we’re
> making a break from OAuth 2’s core architecture but doing so for very
> specific reasons.
>
>  — Justin
>
> On Jan 13, 2020, at 8:54 PM, Richard Backman, Annabelle <
> [e-mail]> wrote:
>
> It’s not just about the initial communication, though. I the key thing to
> emphasize is the decoupling the protocol from delegation channels, which
> addresses the aforementioned security/complexity issues and also provides a
> path to support future delegation channel types without significant changes
> to the protocol (unlike OAuth 2.0, where extensions like Device Flow and
> PAR introduce substantial changes to the core protocol flow on both client
> and AS). Since the protocol isn’t assuming a particular front channel, it’s
> easier to add support for a new one.
>
> Proposal, altered from Dick’s suggestion:
> 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, an
> extension of OAuth 2.0. This protocol will be decoupled from delegation
> channels such as an end user’s web browser and operate primarily through a
> channel between the client and the authorization server, avoiding many of
> the security concerns and technical challenges of OAuth 2.0 and providing a
> non-invasive path for adding support for future types of clients and
> delegation channels.
>
> –
> Annabelle Richard Backman
> AWS Identity
>
>
> *From: *Dick Hardt <[e-mail]>
> *Date: *Monday, January 13, 2020 at 4:35 PM
> *To: *"Richard Backman, Annabelle" <[e-mail]>
> *Cc: *Justin Richer <[e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *Re: [Txauth] alternative charter writeup
>
> I agree, some more "why" would help a broader audience understand the
> motivations. How about this change to the first paragraph?
>
> 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, an
> extension of OAuth 2.0. In contrast to OAuth 2.0, 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, which will mitigate many of the security concerns and
> technical challenges of OAuth 2.0.
>
>
> On Mon, Jan 13, 2020 at 3:38 PM Richard Backman, Annabelle <
> [e-mail]> wrote:
>
> While I agree with the goals stated in this charter, if I read this from
> the perspective of someone who hasn’t been our meetings or listened to
> Justin’s presentations, I’m hard pressed to see what the point of this
> group is, relative to the OAuth WG. I’d expect this charter to provide at
> least a cursory explanation of what problem it is trying to solve. In this
> case, the problem should be partially defined in relation to OAuth. What
> will this WG do that the OAuth WG hasn’t already done or isn’t already
> doing?
>
> How about adding something like the following to paragraph 2:
>
> The protocol will mitigate many of the security concerns and technical
> challenges of OAuth 2.0 by communicating over secure channels between the
> client and the authorization server, and minimizing the amount of
> information transmitted over untrusted channels.
>
> –
> Annabelle Richard Backman
> AWS Identity
>
>
> *From: *Txauth <[e-mail]> on behalf of Dick Hardt <
> [e-mail]>
> *Date: *Friday, January 10, 2020 at 6:57 PM
> *To: *Justin Richer <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *Re: [Txauth] alternative charter writeup
>
> 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
>
>
>