Re: [Txauth] alternative charter writeup

[Thomas Hardjono <[e-mail]>]

Yes, I see that sentence ("This protocol will allow an authorizing party to delegate access to client software through an authorization server"). That's very specific, which is good.

Just wanted to be sure that the bullet further below ("Delegation between multiple users") also makes sense given that the first sentence is talking about delegation to a piece of software.

It’s a big jump between (i) a person delegating to a piece of software, to (ii) a person delegating to another person.

Sorry for being pedantic.



-- thomas --



-----Original Message-----
From: Justin Richer <[e-mail]>
Date: Thursday, January 16, 2020 at 5:50 PM
To: Thomas Hardjono <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Txauth] alternative charter writeup

I get that, but that’s why the proposed charter text tries to be very explicit about who is delegating to whom (or what) and for what purpose. That’s why delegation to software and delegation between users are both listed separately. 

 — Justin

> On Jan 16, 2020, at 4:07 PM, Thomas Hardjono <[e-mail]> wrote:
> 
> The problem is that the word "delegation" is generally a very loaded term.
> 
> I understand that WGs need wiggle room, but I'm concerned that this kind of loose wording may cause confusion down the road.
> 
> 
> 
>>> What I think is very much out of scope is cross-domain policy processing.
> 
> Agree.
> 
> 
> 
> -----Original Message-----
> From: Txauth <[e-mail]> on behalf of Justin Richer <[e-mail]>
> Date: Thursday, January 16, 2020 at 11:54 AM
> To: Thomas Hardjono <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: [Txauth] alternative charter writeup
> 
> On Jan 16, 2020, at 11:43 AM, Thomas Hardjono <[e-mail]> wrote:
>> 
>> 
>> Looks good, but I have a clarification question:
>> 
>>>>> - Delegation between multiple users
>> 
>> What does this mean exactly?
>> 
>> Is it the "multi-hop" delegation (Alice to Bob to Charlize to ...)
>> 
>> Or does it only the "1-hop" delegation concurrently (Alice to Bob; Alice to Charlize; Alice to…)
> 
> My thinking was that at the very least we want to allow the person running the client software and the person doing the authorization to be different people. This is the UMA use case (Alice to bob) and the CIBA use case (agent getting someone to log in). I think chaining can follow that, where Bob can then let Charlie do something. This is also along the lines of the token exchange model of OAuth 2, with continuously down-scoped access.
> 
> What I think is very much out of scope is cross-domain policy processing. 
> 
> — Justin
> 
>> 
>> -- thomas --
>> 
>> 
>> 
>> -----Original Message-----
>> From: Txauth <[e-mail]> on behalf of Justin Richer <[e-mail]>
>> Date: Thursday, January 16, 2020 at 10:46 AM
>> To: "[e-mail]" <[e-mail]>
>> Cc: "[e-mail]" <[e-mail]>, "Richard Backman, Annabelle" <[e-mail]>, Benjamin Kaduk <[e-mail]>, Dick Hardt <[e-mail]>
>> Subject: Re: [Txauth] alternative charter writeup
>> 
>> Here’s my updated text incorporating the feedback so far:
>> 
>> 
>> 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 (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 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. 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 resource access
>> 
>> - Approval of identity claims and multiple resources in a single interaction
>> 
>> - Delegation between multiple users
>> 
>> - 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
>> 
>> 
>> 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.
>> 
>> 
>> 
>> 
>> 
>> It’s definitely a lot, but I think we’ve got a good handle on what we’re working on, and what the boundaries are. I think this is both too much of an effort and too much of a break to do this in the OAuth WG, where there’s already still plenty of work to be done. We’re leaning a lot on lessons learned from the OAuth 2 world and its extensions, including OIDC and UMA2. We’ve got the attention of a lot of the right people to start this as well.
>> 
>> So to the AD’s: Ben and Roman — what’s the next step? This should be a new working group and like to get it started so that we can have our first meeting in Vancouver.
>> 
>> — Justin
>> 
>> 
>> On Jan 14, 2020, at 12:12 AM, Dick Hardt <[e-mail]> wrote:
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Txauth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>> 
>> 
>> -- 
>> Txauth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
> 
> -- 
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
> 
>