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

[Torsten Lodderstedt <[e-mail]>]

Justin, 

> On 21. Mar 2020, at 17:46, Justin Richer <[e-mail]> wrote:
> 
> Torsten, what if we walk that back to:
> 
>  - Support for multiple access tokens in a single request

I think this should be a requirements wrt the response and needs text about who determines the split.

“…  in a single response at the discretion of the AS or as requested by the client” seems appropriate in my opinion.

Note: this slightly reduces the solution space since it would not allow to implement RS-specific access tokens in Multi RS setups using the “super refresh token" pattern. That’s fine with me since I anyway believe issuing all access tokens at once is easier to handle for the client. The “super refresh token” pattern in contrast requires the client to know the boundaries between RSs.  

>  - Support for directed, audience-restricted access requests

Can you please explain what this means? I understand "directed, audience-restricted access tokens” but what are a "directed, audience-restricted access requests"

> 
> I propose that we split these because I think the two of them are useful separately, and considering them separately might influence how we end up solving it overall. I understand that you’re looking at a use case that combines both of them, and I think enabling that makes some sense. 

Thanks for your proposal. 

best regards,
Torsten. 

> 
>  — Justin
> 
>> On Mar 21, 2020, at 9:18 AM, Torsten Lodderstedt <[e-mail]> wrote:
>> 
>> Hi Dick, 
>> 
>>> On 20. Mar 2020, at 01:57, Dick Hardt <[e-mail]> wrote:
>>> 
>>> Rereading the charter I would consider the proposed charter change:
>>> 
>>> - Support for directed, audience-restricted access tokens in multi-RS deployments
>>> 
>>> To be covered by the two highlighted lines below:
>>> 
>>> 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
>>> 
>>> Torsten: Does the scope of fine-grained access combined with approval of access to multiple resources cover your requirements?
>> 
>> I initially thought “Approval of access to multiple resources and APIs in a single interaction” would do. But obviously it doesn’t mention access tokens and the charter, in general, is quiet regarding desired capabilities for token issuance and relationships between access tokens and resources.  
>> 
>> It also became obvious during the recent discussions there are different interpretations, expectations, and objectives. 
>> 
>> I therefore think another bullet to explicitly spell this out makes a lot of sense. 
>> 
>> In order to cover more use cases and be more explicit at the same time, I suggest the following wording:
>> 
>> - Support for directed, audience-restricted access tokens in multi-RS deployments at client or AS discretion
>> 
>>> 
>>> Note that we are not stating how we do it, just what is in scope.
>> 
>> Absolutely, I can think of various ways to implement it, but that’s another step. First we need to agree on the objectives. 
>> 
>> thanks,
>> Torsten. 
>> 
>>> 
>>> /Dick
>>> 
>>> On Thu, Mar 19, 2020 at 1:48 PM Justin Richer <[e-mail]> wrote:
>>> On Mar 19, 2020, at 4:41 PM, Torsten Lodderstedt <[e-mail]> wrote:
>>>> 
>>>>> Am 19.03.2020 um 21:07 schrieb Justin Richer <[e-mail]>:
>>>>> 
>>>>> I think this is already in scope in the ways that I’ve described,
>>>> 
>>>> Given our recent discussion, I don’t see how it is already in scope 
>>> 
>>> What I mean is that a client can already ask for separate tokens and use the “resources” block to describe which resource servers it wants. However, right now, it’s up to the client to determine what the split is — either by asking for separate tokens in either the single-token format (with multiple requests) or multi-token format (with a single request). 
>>> 
>>>> 
>>>>> with the caveat that identifying "the RS" is really, really hard to do.
>>>> 
>>>> I don’t think it’s difficult to use URLs to identify at least „destinations“, it works for cookies as well. 
>>> 
>>> I think that’s an aspect, but not the only aspect. I’m trying to push back against optimizing for that one kind of identity. And cookies have all kinds of rules for paths and domains and origins that protect them, so if that’s the model we’re arguing for we need to at least consider all of that. We also need to consider that cookies fail in a lot of ways! :)
>>> 
>>>> 
>>>>> What if instead it’s:
>>>>> 
>>>>> - Support for directed, audience-restricted access tokens in multi-RS deployments
>>>>> 
>>>>> Would that work? To me the difference is that it’s getting away from a fixed notion of what an “RS” is and more towards the notion of getting a token directed to a specific set of actions and/or locations.
>>>> 
>>>> wfm, as long it is clear the AS/RS determines the boundaries.
>>> 
>>> Ultimately they always do, and they’ll always need to deal with the situation where a client asks for rights that cross boundaries. The question is what to do in those situations, and I think there’s a lot more discussion we need to have on that front! Do we allow the AS to split a token request, do we have errors for this, do we have a client indicate that it can receive split tokens … etc. I think it’s an interesting area, but complex and not nearly as clean-cut as your own use case and deployment might let it be.
>>> 
>>> — Justin
>>> 
>>>> 
>>>> best regards,
>>>> Torsten.
>>>> 
>>>>> 
>>>>> — Justin
>>>>> 
>>>>>> On Mar 19, 2020, at 2:08 PM, Torsten Lodderstedt <torsten=[e-mail]> wrote:
>>>>>> 
>>>>>> 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
>>>>> 
>>>>> -- 
>>>>> Txauth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>> 
>>> -- 
>>> Txauth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>