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

[Dick Hardt <[e-mail]>]

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?

Note that we are not stating how we do it, just what is in scope.

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