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

[Vladimir Dzhuvinov <[e-mail]>]

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