Re: [Txauth] alternative charter writeup

[Dick Hardt <[e-mail]>]

What I have understood we are enabling is a separation between the user
using the client software, and the user that is the resource owner.

Justin: is that what you had in mind?
ᐧ

On Thu, Jan 16, 2020 at 3:17 PM Thomas Hardjono <[e-mail]>
wrote:

> 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
> >
> >
>
>
>
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>