FHIR Chat · OAuth Delegation/Impersonation · Security and Privacy

Stream: Security and Privacy

Topic: OAuth Delegation/Impersonation


view this post on Zulip David Pyke (Aug 18 2021 at 13:46):

RFC8693 was introduced in January of 2020 and gives the semantics for Delegation and Impersonation in OAuth.

Has anyone read through this and have thoughts about it? Are there issues with it? Has anyone implemented it?

view this post on Zulip David Pyke (Aug 18 2021 at 15:51):

I'll give a promise of half a cheese sandwich to anyone that has information about this RFC

view this post on Zulip Gino Canessa (Aug 18 2021 at 16:34):

You may get better responses in the #smart stream. (holds out hand for half-sandwich ;-)

That said, this looks complementary to several RFCs that SMART App Launch already references (especially in the draft of v2).. e.g., the next version has information about token introspection, with links to RFC7662, which RFC8693 also references.

My quick gut reaction is that this defines things that are compatible with SMART v2, but that have so far been left out of scope for it. That said, I would highly recommend getting the opinion of someone smarter than me (see what I did there? =).

view this post on Zulip Vassil Peytchev (Aug 18 2021 at 16:36):

Did you mean "someone FHIR SMARTer than me"?

view this post on Zulip David Pyke (Aug 18 2021 at 16:40):

This is more about the token exchange aspect and if anyone has implemented but you have a promise of half a cheese sandwich.

view this post on Zulip David Pyke (Aug 18 2021 at 16:40):

I'll post it in SMART and see what they say

view this post on Zulip Gino Canessa (Aug 18 2021 at 16:41):

Nice. I was going to do the capitalization, but I thought I would leave some work for the reader =). I missed the opportunity for the 'FHIR' substitution entirely. I tip my :top_hat: to you.

view this post on Zulip Gino Canessa (Aug 18 2021 at 16:43):

Yes, the token exchange portion hasn't been addressed (in SMART) yet. SMART v2 just added the introspection piece (which is compatible), so this is the next layer would be another layer on top of that.

It's getting close to publication, so I don't know that a scope change of that size would still be possible this round, but there's nothing (that I know of) that would stop someone from using this either.

view this post on Zulip Josh Mandel (Aug 18 2021 at 16:45):

We've had plenty of discussion on token exchange over the years; it's not something we've put in scope for SMART App Launch or for SMART Backend Services though.

view this post on Zulip Josh Mandel (Aug 18 2021 at 16:47):

The semantics of token exchange are most straightforward when you're creating a derived token with a set of scopes that's a strict subset of what you've already got -- but even there, the "underlying permissions system" that enforces additional rules based on a given client registration or a given user's privileges... these have to be intersected too. It's significant complexity, and we haven't needed it for our core use cases yet.

view this post on Zulip John Moehrke (Aug 18 2021 at 18:21):

most all of this is not special to healthcare... and hence why I have resisted pulling peice-by-peice into healthcare. The interaction between the security layer and the healthcare layer is important for us to characterize (such as scopes, and attributes).


Last updated: Apr 12 2022 at 19:14 UTC