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

[Mike Jones <[e-mail]>]

I support adding this requirement to the charter.

				-- Mike

-----Original Message-----
From: Txauth <[e-mail]> On Behalf Of Torsten Lodderstedt
Sent: Thursday, March 19, 2020 11:09 AM
To: [e-mail]
Cc: Vladimir Dzhuvinov <[e-mail]>
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 <[e-mail]> wrote:
> 
> 
> On 19/03/2020 19:11, Torsten Lodderstedt wrote:
>> On 19. Mar 2020, at 17:47, Justin Richer <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/txauth