Subject: [Txauth] Call for charter consensus - TxAuth WG

From: Yaron Sheffer <[email-masked]>
Date: Fri, 06 Mar 2020 18:44:53 +0200

Hi Everyone,
 
It appears that momentum is forming around the proposed formation of a TxAuth working group.  We’d like to more formally gauge interest in proceeding with this work.  Please do so by responding to the following questions:
 
1.  Do you support the charter text provided at the end of this email?  Or do you have major objections, blocking concerns or feedback (if so please elaborate)?
 
2.  Are you willing to author or participate in the development of the drafts of this WG?
 
3.  Are you willing to help review the drafts of this WG?
 
4.  Are you interested in implementing drafts of this WG?
 
The call will run for two weeks, until March 21. If you think that the charter should be amended In a significant way, please reply on a separate thread.
 
The feedback provided here will help the IESG come to a decision on the formation of a new WG. Given the constraints of the chartering process, regardless of the outcome of this consensus call, we will be meeting in Vancouver as a BoF.
 
Thanks,
Yaron and Dick
 
--- Charter Text Follows ---

This group is chartered to develop a fine-grained delegation protocol for authorization, identity, and API access. This protocol will allow an authorizing party to delegate access to client software through an authorization server. It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove unnecessary dependence on a browser or user-agent for coordinating interactions. 

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.0 which is initiated by the client redirecting the user’s browser). The client and AS will involve a user to make an authorization decision as necessary through interaction mechanisms indicated by the protocol. This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 and provides a non-invasive path for supporting future types of clients and interaction channels.

Additionally, the delegation process will allow for:

- Fine-grained specification of access
- Approval of AS attestation to identity claims
- Approval of access to multiple resources and APIs in a single interaction
- Separation between the party authorizing access and the party operating the client requesting access
- A variety of client applications, including Web, mobile, single-page, and interaction-constrained 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 conveying user, software, organization, and other pieces of information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information through the delegation process (including identity)

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 migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible.

This group is not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions not necessarily compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be developed in the OAuth Working Group, including functionality back-ported from the protocol developed here to OAuth 2.0.

The group is chartered to develop mechanisms for applying cryptographic methods, such as JOSE and COSE, to the delegation process. This group is not chartered to develop new cryptographic methods. 

The initial work will focus on using HTTP for communication between the client and the authorization server, taking advantage of optimization features of HTTP2 and HTTP3 where possible, and will strive to enable simple mapping to other protocols such as COAP when doing so does not conflict with the primary focus.

Milestones to include:
 - Core delegation protocol
 - Key presentation mechanism bindings to the core protocol for TLS, detached HTTP signature, and embedded HTTP signatures
 - Identity and authentication conveyance mechanisms
 - Guidelines for use of protocol extension points

---

From: Aaron Parecki <[email-masked]>
Date: Sat, 7 Mar 2020 09:47:29 -0800

> 1.  Do you support the charter text provided at the end of this email?  Or do you have major objections, blocking concerns or feedback (if so please elaborate)?

Yes

> 2.  Are you willing to author or participate in the development of the drafts of this WG?

Yes

> 3.  Are you willing to help review the drafts of this WG?

Yes

> 4.  Are you interested in implementing drafts of this WG?

Yes

----
Aaron Parecki
aaronparecki.com
@aaronpk

On Fri, Mar 6, 2020 at 8:45 AM Yaron Sheffer <[email-masked]> wrote:
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Aleksei Petrov <[email-masked]>
Date: Sat, 7 Mar 2020 21:27:17 +0100

>
> 1.  Do you support the charter text provided at the end of this email?  Or
> do you have major objections, blocking concerns or feedback (if so please
> elaborate)?

Yes

Yes

Yes

Yes

----
Aleksei Petrov | Senior Software Engineer | User Platform

Spotify AB
Regeringsgatan 19
111 53 Stockholm

On Fri, Mar 6, 2020 at 5:45 PM Yaron Sheffer <[email-masked]> wrote:

> Hi Everyone,
>
> It appears that momentum is forming around the proposed formation of a
> TxAuth working group.  We’d like to more formally gauge interest in
> proceeding with this work.  Please do so by responding to the following
> questions:
>
> 1.  Do you support the charter text provided at the end of this email?  Or
> do you have major objections, blocking concerns or feedback (if so please
> elaborate)?
>
> The call will run for two weeks, until March 21. If you think that the
> charter should be amended In a significant way, please reply on a separate
> thread.
>
> The feedback provided here will help the IESG come to a decision on the
> formation of a new WG. Given the constraints of the chartering process,
> regardless of the outcome of this consensus call, we will be meeting in
> Vancouver as a BoF.
>
> Thanks,
> Yaron and Dick
>
> This group is chartered to develop a fine-grained delegation protocol for
> authorization, identity, and API access. This protocol will allow an
> authorizing party to delegate access to client software through an
> authorization server. It will expand upon the uses cases currently
> supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth
> 2.0) to support authorizations scoped as narrowly as a single transaction,
> provide a clear framework for interaction among all parties involved in the
> protocol flow, and remove unnecessary dependence on a browser or user-agent
> for coordinating interactions.
>
> 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.0 which is initiated by the client
> redirecting the user’s browser). The client and AS will involve a user to
> make an authorization decision as necessary through interaction mechanisms
> indicated by the protocol. This decoupling avoids many of the security
> concerns and technical challenges of OAuth 2.0 and provides a non-invasive
> path for supporting future types of clients and interaction channels.
>
> - Mechanisms for conveying user, software, organization, and other pieces
> of information used in authorization decisions
> - Mechanisms for presenting tokens to resource servers and binding
> resource requests to tokens and associated cryptographic keys
> 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 migrating from OAuth 2.0 and OpenID Connect to the new
> protocol where possible.
>
> This group is not chartered to develop extensions to OAuth 2.0, and as
> such will focus on new technological solutions not necessarily compatible
> with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be
> developed in the OAuth Working Group, including functionality back-ported
> from the protocol developed here to OAuth 2.0.
>
> The group is chartered to develop mechanisms for applying cryptographic
> methods, such as JOSE and COSE, to the delegation process. This group is
> not chartered to develop new cryptographic methods.
>
> The initial work will focus on using HTTP for communication between the
> client and the authorization server, taking advantage of optimization
> features of HTTP2 and HTTP3 where possible, and will strive to enable
> simple mapping to other protocols such as COAP when doing so does not
> conflict with the primary focus.
>
> Milestones to include:
>  - Key presentation mechanism bindings to the core protocol for TLS,
> detached HTTP signature, and embedded HTTP signatures

---

From: "Amanjeev Sethi" <[email-masked]>
Date: Sat, 07 Mar 2020 10:06:29 -0500

Hello Everyone,

I am relatively new here and in fact only been reading OIDC spec for past 6-8 months. I am still trying to grasp the TxAuth by watching Justin's talks and posts. I am here to mostly see and hopefully participate in some corners of this spec. 

> 1.  Do you support the charter text provided at the end of this email?  
> Or do you have major objections, blocking concerns or feedback (if so 
> please elaborate)?

Yes.

Yes

Yes

Yes

On Fri, Mar 6, 2020, at 11:44 AM, Yaron Sheffer wrote:
> 1.  Do you support the charter text provided at the end of this email?  
> Or do you have major objections, blocking concerns or feedback (if so 
> please elaborate)?
>  
> charter should be amended In a significant way, please reply on a 
> separate thread.
>  
> This group is chartered to develop a fine-grained delegation protocol 
> for authorization, identity, and API access. This protocol will allow 
> an authorizing party to delegate access to client software through an 
> 2.0) to support authorizations scoped as narrowly as a single 
> transaction, provide a clear framework for interaction among all 
> parties involved in the protocol flow, and remove unnecessary 
> dependence on a browser or user-agent for coordinating interactions. 
> 
> 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.0 which is initiated by 
> the client redirecting the user’s browser). The client and AS will 
> involve a user to make an authorization decision as necessary through 
> interaction mechanisms indicated by the protocol. This decoupling 
> avoids many of the security concerns and technical challenges of OAuth 
> 2.0 and provides a non-invasive path for supporting future types of 
> clients and interaction channels.
> 
> - Mechanisms for conveying user, software, organization, and other 
> pieces of information used in authorization decisions
> attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the 
> new protocol where possible.
> 
> such will focus on new technological solutions not necessarily 
> compatible with OAuth 2.0. Functionality that builds directly on OAuth 
> 2.0 will be developed in the OAuth Working Group, including 
> functionality back-ported from the protocol developed here to OAuth 2.0.
> 
> methods, such as JOSE and COSE, to the delegation process. This group 
> is not chartered to develop new cryptographic methods. 
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 7 Mar 2020 16:17:47 +0100

Hi,

> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <[email-masked]>:
> 
> Hi Everyone,
>  

I‘m in although I have to admit I‘m slightly concerned the scope of the charter is too broad, e.g. identify alone is a huge topic.

We need to keep an eye on this aspect in order to make sure, the group is able to work effectively and the specs we will be producing are as simple as possible and foster interoperability.

> 2.  Are you willing to author or participate in the development of the drafts of this WG?

yes

> 3.  Are you willing to help review the drafts of this WG?

yes

> 4.  Are you interested in implementing drafts of this WG?

yes

best regards,
Torsten.

---

From: David Skaife <[email-masked]>
Date: Sat, 7 Mar 2020 15:53:10 +0000

Hi,

I'm fairly new to this group (and the OAuth group) but I'm hoping to
participate and help here.

Yes. I share some of the same concerns that Torsten has highlighted, but
overall I'm happy with the charter text. I like that it explicitly states
that we're aiming to create a *protocol*, not a *framework *(like OAuth 2.0
was).

> 2.  Are you willing to author or participate in the development of the
drafts of this WG?

Yes, I will help as much as my time permits.

Yes.

Yes.

Many thanks,
David Skaife

On Sat, Mar 7, 2020 at 3:17 PM Torsten Lodderstedt <torsten=
[email-masked]> wrote:

> I‘m in although I have to admit I‘m slightly concerned the scope of the
> charter is too broad, e.g. identify alone is a huge topic.
>
> We need to keep an eye on this aspect in order to make sure, the group is
> able to work effectively and the specs we will be producing are as simple
> as possible and foster interoperability.
>
> >
> for authorization, identity, and API access. This protocol will allow an

---

From: Leif Johansson <[email-masked]>
Date: Sun, 8 Mar 2020 20:44:01 +0100

Skickat från min iPhone

> 6 mars 2020 kl. 17:45 skrev Yaron Sheffer <[email-masked]>:
> 
> Hi Everyone,
>  

Yes

> 2.  Are you willing to author or participate in the development of the drafts of this WG?

Review more than author probably

Yes

Yes

---

From: Florian Biesinger <[email-masked]>
Date: Mon, 9 Mar 2020 10:15:09 +0100

4x yes as well.

-- 
/Flo

-- 
Florian Biesinger ♫ | Backend Engineer | [email-masked] | +46 70 36 72
133

Spotify GmbH
c/o Mindspace
Krausenstraße 9
10117 Berlin

Get Spotify here! <http://www.spotify.com/se/get-spotify/overview/>

This e-mail (including any attachments) may contain information that
is confidential and/or privileged. It is intended only for the
recipient(s). If you have reason to believe that you are not the intended
recipient of this e-mail, please contact the sender immediately and delete
the e-mail from your computer.

---

From: Lee McGovern <[email-masked]>
Date: Mon, 9 Mar 2020 10:08:24 +0000

Yes

Yes

Yes

No

Lee McGovern | IAM Architect | VICE PRESIDENT | Information Technology
Swiss Re Management Ltd | Mythenquai 50/60, 8022 ZURICH, SWITZERLAND
Direct: +41 43 285 70 17 Fax: +41 43 282 70 17 E-mail: [email-masked]<mailto:[email-masked]>

On Fri, Mar 6, 2020 at 5:45 PM Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:
Hi Everyone,

Thanks,
Yaron and Dick

--- Charter Text Follows ---

Milestones to include:

--
Txauth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

This e-mail, including attachments, is intended for the person(s) or company named and may contain confidential and/or legally privileged information.

Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please delete this message and notify the sender.
All incoming and outgoing e-mail messages are stored in the Swiss Re Electronic Message Repository.
If you do not wish the retention of potentially private e-mails by Swiss Re, we strongly advise you not to use the Swiss Re e-mail account for any private, non-business related communications.

---

From: Daniel DeGroff <[email-masked]>
Date: Mon, 9 Mar 2020 21:49:08 -0600

Hi,

Yes

Yes

Yes

Yes

Daniel
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Tue, 10 Mar 2020 09:47:35 -0400

Yes.

> 2.  Are you willing to author or participate in the development of the drafts of this WG?

Yes, and I am volunteering to edit.

Yes.

> 4.  Are you interested in implementing drafts of this WG?

Yes, and I have implemented one of the input drafts.

---

From: Sudipta Pal <[email-masked]>
Date: Tue, 10 Mar 2020 19:43:23 +0530

Yes.

Yes.

Yes

---

From: Dmitri Zagidulin <[email-masked]>
Date: Tue, 10 Mar 2020 12:07:25 -0400

Yes.

> 2.  Are you willing to author or participate in the development of the
drafts of this WG?

Yes, and am also volunteering to help edit.

Yes.

> 4.  Are you interested in implementing drafts of this WG?

Yes, and I have implemented one of the input drafts (client side and server
side).

---

From: Matthew De Haast <[email-masked]>
Date: Wed, 11 Mar 2020 13:34:16 +0200

Yes

Yes

Yes

Yes

Matt

---

From: Stephen Moore <[email-masked]>
Date: Thu, 12 Mar 2020 10:43:28 -0400

On the 4 questions for the initial Call for charter consensus, I'm a YES.
(I joined the mailing list after it went out...)

My main interest is in figuring out how to make this work for IoT in a
'home use' setting. (Although that doesn't mean it can't work in larger
industrial settings.)

-steve
https://www.moorelabs.com/

On Thu, Mar 12, 2020 at 10:33 AM Justin Richer <[email-masked]> wrote:

>
>
> *From: *Yaron Sheffer <[email-masked]>
> *Subject: **[Txauth] Call for charter consensus - TxAuth WG*
> *Date: *March 6, 2020 at 11:44:53 AM EST
> *To: *"[email-masked]" <[email-masked]>
>
> Hi Everyone,
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 17 Mar 2020 17:12:01 +0000

I share the concerns about including identity in the charter that were expressed by Torsten and agreed with by David Skaife.  I'll note that Kim Cameron previously expressed concerns about including identity in his earlier charter critique at https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/.

I'm fine with refactoring the authorization protocol.  But identity should be decoupled from the TxAuth work to focus its scope on areas where innovation is being proposed.  Digital identity can always be added as a layer if needed, just as OpenID Connect layered identity onto OAuth 2.0.

Please revise the charter to remove digital identity from the scope of the work.

Yes

Yes

Not at this time.

				-- Mike

-----Original Message-----
From: Txauth <[email-masked]> On Behalf Of Torsten Lodderstedt
Sent: Saturday, March 7, 2020 7:18 AM
To: Yaron Sheffer <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth WG

Hi,

yes

yes

yes

best regards,
Torsten.

---

From: Justin Richer <[email-masked]>
Date: Tue, 17 Mar 2020 17:20:21 -0400

While I understand the concerns around identity in the charter, and I had initially not included it, I was convinced that the kind of identity protocol that we’re looking at here is a minor addition to the authorization and delegation end of things.

As you know, much of what’s in OIDC is there to fix problems with OAuth 2 when it’s used for identity. If OAuth 2 had solved those problems internally, then OIDC would be much, much simpler and smaller. We’re now starting at a base where those problems don’t exist, but we don’t yet know what other problems there might be. 

The market has shown us that the most common application of OAuth 2 is far and away access to identity information along side access to an API. I think we need to pay attention to that and not make this separate just because we did it that way before. And some of the proposed innovations, including getting and sending VC’s, are all about identity.

Furthermore, this charter does not specify the document and specification structure of the components, nor does it specify the publication order or timing of any documents. I personally think that the identity layer should be separable to an extent, to the point of publishing that layer in its own spec alongside the core authorization delegation system. However, that does not mean that it should be developed elsewhere.

If there is better language to tighten the aspects of an identity protocol that we will explicitly cover, then I would welcome you to suggest an amended text to the charter. However, I believe there is enough interest within the community to work on identity in the context of this protocol, including a large number of people being OK with it in the charter, that it would not be a reasonable thing to remove it.

 — Justin

> On Mar 17, 2020, at 1:12 PM, Mike Jones <Michael.Jones=[email-masked]> wrote:
>