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

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 7 Mar 2020 16:30:32 +0200

This is the future, so

> 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?
Not sure I can be of much help here
> 3.  Are you willing to help review the drafts of this WG?
Yes
> 4.  Are you interested in implementing drafts of this WG?
Yes

Vladimir

-- 
Vladimir Dzhuvinov

---

From: Mike Jones <[email-masked]>
Date: Wed, 18 Mar 2020 20:27:36 +0000

Putting a little more meat on the "identity is a huge topic" comment, let me make a few observations about OpenID Connect and OAuth 2.0.  Most of OpenID Connect Core<https://openid.net/specs/openid-connect-core-1_0.html> creates new identity-specific functionality such as ID Tokens, the UserInfo Endpoint, Claims (including aggregated and distributed claims), authenticated sessions, issuers, key management and key rollover, self-issued identity providers, etc.  Yes, Section 3 (Authentication)<https://openid.net/specs/openid-connect-core-1_0.html#Authentication> describes how to turn an authorization request into an authentication request – which is the core of the relationship between OpenID Connect and OAuth 2.0 – and Section 9 (Client Authentication)<https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication>  is also about the OAuth/Connect interface.  But most of it is not about OAuth or authorization.

That’s even more true when you consider that other OpenID Connect specs are important in many deployments, such as Discovery<http://openid.net/specs/openid-connect-discovery-1_0.html>, Front-Channel Logout<https://openid.net/specs/openid-connect-frontchannel-1_0.html>, Identity Assurance<https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html>, etc.  There’s a lot more to identity than just logging in and returning claims about the end-user.

Therefore, if identity is in scope at all, I agree that it should be a narrow, well-defined slice – for instance maybe a mechanism defining what syntax you use to indicate that a TxAuth authorization request is also an authentication (login) request – which is what the “openid” scope does.  But identity is huge topic.  I believe that we should enable as much reuse of existing identity mechanisms as possible, while still reworking the protocol flows.  Things like session management (including session renewal and logout), identity assurance, and claims about the end-user and about the authentication performed should be explicitly out of scope, to keep us from trying to reinvent all the wheels.

                                                       -- Mike

-----Original Message-----
From: Justin Richer <[email-masked]>
Sent: Tuesday, March 17, 2020 3:47 PM
To: Aaron Parecki <[email-masked]>
Cc: Mike Jones <[email-masked]>; Yaron Sheffer <[email-masked]>; Torsten Lodderstedt <[email-masked]>; [email-masked]
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG

+1

Thanks, Aaron. I think it really is a very narrow slice of identity that we want to cover here, and I’d be happy to get more precise language into the proposed charter before moving forward.

— Justin

> On Mar 17, 2020, at 6:31 PM, Aaron Parecki <[email-masked]<mailto:[email-masked]>> wrote:

> Much of the confusion in the marketplace around OAuth and OpenID

> Connect stems from the fact that they are separate specs developed in

> separate organizations, when really they are two parts to the same

> picture. I am strongly against excluding identity from the charter of

> TxAuth, as I think this is a unique opportunity to bring the two

> aspects together.

> The concern expressed by Kim

> (https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2C

> ahE) around OpenID Connect could also be said about OAuth, namely that

> there will be some amount of confusion around the fact that this spec

> will cover many of the same use cases as OAuth. I think that's fine,

> that's just how we move forward and make progress.

> The other concerns seem vague, e.g. "identity is a huge topic". While

> that may be true, so is authorization, and that alone is not a good

> reason to not do it.

> Perhaps the scope of identity included in TxAuth could be narrowed to

> specify that it's only about communicating identity information, not

> about doing things like identity proofing or identity assurance. That

> might help address some of the other concerns that have been

> expressed.

> ----

> Aaron Parecki

> aaronparecki.com

> @aaronpk

> On Tue, Mar 17, 2020 at 3:06 PM Mike Jones

> <Michael.Jones=[email-masked]<mailto:Michael.Jones=[email-masked]>> wrote:

>> I believe it's significant that four people have expressed concerns with including digital identity in the charter (the only concerns voiced as far as I can tell).  At a minimum, I believe that that warrants making the inclusion or exclusion of digital identity a discussion topic during the upcoming virtual BoF, before adopting any charter.

>> It would be my proposal to initially charter without digital identity and see how far we get with our energies intentionally focused in that way.  If the working group decides to recharter to include digital identity, that can always happen later, after the authorization-focused work has matured, and once there's a clear case to actually do so.

>>                                -- Mike

>> -----Original Message-----

>> From: Justin Richer <[email-masked]<mailto:[email-masked]>>

>> Sent: Tuesday, March 17, 2020 2:20 PM

>> To: Mike Jones <[email-masked]<mailto:[email-masked]>>

>> Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; Torsten Lodderstedt

>> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

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

>> 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]<mailto:Michael.Jones=[email-masked]>> wrote:

>>> 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.

>>> Not at this time.

>>>                              -- Mike

>>> -----Original Message-----

>>> From: Txauth <[email-masked]<mailto:[email-masked]>> On Behalf Of Torsten

>>> Lodderstedt

>>> Sent: Saturday, March 7, 2020 7:18 AM

>>> To: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>

>>> Cc: [email-masked]<mailto:[email-masked]>

>>> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth

>>> WG

>>> Hi,

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

>>>> 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:

>>> 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.

>>> yes

>>> yes

>>> yes

>>> best regards,

>>> Torsten.

>>>> 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

>>>> Txauth mailing list

>>>> [email-masked]<mailto:[email-masked]>

>>>> https://www.ietf.org/mailman/listinfo/txauth

>>> Txauth mailing list

>>> [email-masked]<mailto:[email-masked]>

>>> https://www.ietf.org/mailman/listinfo/txauth

>> Txauth mailing list

>> [email-masked]<mailto:[email-masked]>

>> https://www.ietf.org/mailman/listinfo/txauth

---

From: Mike Jones <[email-masked]>
Date: Thu, 19 Mar 2020 18:28:18 +0000

I support adding this requirement to the charter.

				-- Mike

-----Original Message-----
From: Txauth <[email-masked]> On Behalf Of Torsten Lodderstedt
Sent: Thursday, March 19, 2020 11:09 AM
To: [email-masked]
Cc: Vladimir Dzhuvinov <[email-masked]>
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG

Hi all,

I suggest to add the following requirement to the charter:
	• Support for RS-specific access tokens in Multi-RS deployments 

I don’t mind HOW this requirement is supported in TXAuth. I want to make sure we try to build a protocol that serves the needs of a broad set of deployments. My concern is otherwise TXAuth will be not innovative enough to gain traction in the market rapidly. Speaking for myself, I realised in the last couple of days, mostly in conversations with Justin, that the result of this working group as envisioned now is not of particular interest to us (yes.com) because it does not solve our real problems. 

And here is my explanation: 

OAuth traditionally has the philosophy of a single access token. That’s fine for single service deployments, but it had reached its limits already before RFC6749 was published. There are a real implementations out there forcing clients to use different access tokens for different services, typically for privacy and security reasons. There is also an “ancient" technology called Kerberos that uses exactly this pattern and is well known for security, performance, and scalability. 

And there are even more examples today for multi API environments that would benefit from that feature: 
	• Open banking: most banks I worked with have multiple APIs, segregation between APIs is today achieved by maintaining different grants, basically resulting in the fact that the users cannot consent to different services at once. What a terrible UX!
	• Everyone is doing micro services today. Have you every thought about the coupling caused by a single token across micro services? This reminds me of how easy it is to test services independently using self-contained RS-specific tokens.
	• IoT - every device in a household is a potential RS (in my opinion). Conveying all necessary data in an access token needed to meet access control decisions locally would be a huge benefit in terms of performance and decoupling. Using symmetric cryptography for token integrity, authenticity and confidentiality would result in lower compute requirements.

Since we are preparing to define a completely new protocol for API access authorization and delegation, I think this new protocol should support this kind of scenarios. It will require significant work to get it right and simple, but if we just stick to the “a single access token is enough” mantra, we miss the chance to give implementers a broader range of design choices out of the box and we won’t success in achieving true interoperability.

Here are more advantages we can gain by supporting such a feature: 
	• Privacy:
		• A single access token can be used to track user across services.
		• RS-specific access tokens cannot.
		• RS-specific access tokens can also be encrypted to protect data confidentiality in transit.
	• Security: RS-specific access tokens have a baseline replay detection.
	• Performance: RS-specific access tokens allow the AS to convey all data required to authorize an API call in a token (e.g. a JWT) and to RS to meet the access control decision based on that data. This is a huge advantage in terms of performance, scalability and cost since there is no need for Token Introspection or other kinds of access to another services or database.

What do you think?

best regards,
Torsten. 

> On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov <[email-masked]> wrote:
> 
> 
> On 19/03/2020 19:11, Torsten Lodderstedt wrote:
>> On 19. Mar 2020, at 17:47, Justin Richer <[email-masked]> wrote:
>>> Well, it’s in scope as much as describing any other aspect of what the token is for and what it represents is in scope. That is alongside things like the intended audience of the token, the access rights for the token, the presentation keys the token is bound to, etc. It could be information in the token text itself (like a JWT), it could be introspected from the AS, it could be referenced in some other way. So if we can define identity aspects in that, then we’re fine in covering it there. 
>>> 
>>> But here’s the thing: none of that has an impact on the core protocol. That is entirely up to the AS and the RS to agree on, and the client never sees or has any influence on it. That portion of the protocol is completely opaque to the client. Therefore, it doesn’t really affect the authorization and delegation portions of the client talking to the AS and the client talking to the RS.
>>> 
>>> This does raise the question of what our bar of interoperability is going to be with TxAuth: do we expect independent AS and RS implementations to talk to each other? That’s not something OAuth 2 was ever concerned with, though obviously JWT and introspection are both from the OAuth2 WG and solve that problem.
>> There are two aspects to it: interoperability and vendor support. 
>> 
>> Interoperability between AS and RS is important if deployments want to combine pre-packaged TXAuth and API implementations. I think that makes a lot of sense and should be included in the charter.
> 
> +1
> 
> The current OAuth 2.0 status quo of the largely unspecified 
> relationship between AS and RS is also making the life of web & sec 
> framework maintainers difficult. We witnessing this with people 
> integrating the OAuth SDK into frameworks. Vittorio's recent work to 
> put together a minimal interoperable JWT profile for access tokens is 
> helpful, but it has come after the fact. And there is not agreement on 
> things like authorising access to claims.
> 
> Integrating apps (RSs) with TxAuth should be straightforward and simple.
> 
> This can have a enormous effect on adoption.
> 
> 
>> Vendors support: vendor support when it comes to "what can go into an access token" and "what can be conveyed in a token introspection response” greatly deviates in my observation. This also means implementation use vendors specific features restricting their ability to use other solutions. TXAuth should aim at improving the situation.  
> 
> +1
> 
> 
>> I also think it is a good exercise for the group to think the whole process "from the end”. The purpose of TXAuth (and OAuth) is not to provide clients with access tokens. The purpose is to enable API request processing in a secure manner. What it really takes to achieve that goal is not obvious if the work always stops at the “you have your access token, good luck” stage. 
> 
> +1
> 
> Vladimir
> 
> 
> --
> Txauth mailing list
> [email-masked]

--
Txauth mailing list
[email-masked]