Clarification for JWT-only access

[davidbernick]

For issues brought up here, #40, we are trying to clarify that GA4GH explicitly supports JWT-only auth though it is not the most recommended way to use it.

[davidbernick]

Hi @mikael-linden and @martin-kuba -- this is a small PR for clarification mostly. The idea is that if /userinfo is returned as a JWT, a closely knit group of Clearinghouses may pass it amongst themselves. For instance, Institution A and B have explicit legal and security agreements (known as ISAs) that bind their systems contractually. For that use-case, using the JWT itself as an authentication mechanism should be acceptable. In other words, allowing trust between systems (if they accept risk) WITHOUT a full OIDC Flow. What IS implied is that somewhere within one of these two systems, explicit OIDC Flow happened to get the information in the first place.

This was always implied by the spec but I put this in to make it more explicit.

[davidbernick]

@mikael-linden @cdvoisin is there more that's required here?

[cdvoisin]

I'm not sure NIH and ecosystem genomics platforms will be needing this anymore. I'd prefer not to have to worry about the implications of using a flow like this if other options can solve the need. Perhaps we can sit on this or reject it for now and reopen in the future if we need it?

[davidbernick]

I'm not sure NIH and ecosystem genomics platforms will be needing this anymore. I'd prefer not to have to worry about the implications of using a flow like this if other options can solve the need.

I think we need it because the “interconnected” systems like terra->gen3 or terra->7 bridges want to do something like this with RAS (one system talks to RAS and Gets VISAs and can use a Passport JWT to authenticate/authorize to another system).

it’s not urgent because we said it’s an acceptable use case and showed this PR as evidence to that. Remember this is the PR that you and I worked on together...

[mikael-linden]

I understood the idea is a Clearinghouse has a local agreement that it can pass the Userinfo response JWT to a downstream party. Is defining that kind of flow in the scope of the AAI OIDC profile? In general, the profile defines the flow between the Broker and the Clearinghouse.

[davidbernick]

I don't know that it necessarily SHOULD be, but in practical terms, we've gotten many questions of, "Can the output of /userinfo be used for authentication?" and if so "Can we dictate the format of that /userinfo?". Because the spec doesn't say one way or another, actual groups implementing were confused over what it SHOULD be. So I figured making that clearer was good. In particular, NIH and other US orgs have had this question. They want to know if the output of /userinfo can be used as downstream authentication. I think "yes" and that's intended by the spec. I think we should make that explicit as opposed to implied. Or maybe as an appendix?

[mikael-linden]

we've gotten many questions of, "Can the output of /userinfo be used for authentication?" and if so "Can we dictate the format of that /userinfo?". Because the spec doesn't say one way or another, actual groups implementing were confused over what it SHOULD be. So I figured making that clearer was good.

Would a separate FAQ be better than including implementation hints or good practices to the normative spec itself? I'm worried about the specification bloat.
Also the current proposed text is a bit cryptic -- I had to read it together with your comment above to understand it.

[cdvoisin]

When I added signed JWT responses in the v1.0 AAI spec, I was thinking about use cases where reverse proxies and more complicated layers of infrastructure may want to have a way to retain the broker's authority in the response. When it comes to using a /userinfo as an access token, there are several areas that we would need to tighten up when it comes to security assumptions and compatibility (when it is only to use use these as access tokens and when not to). This adds bloat as Mikael has indicated, and can make the spec harder to implement from all layers of participants in the federation.

Instead of moving toward this backdoor process to get scoped tokens, there are several other mechanisms that are closer to standard (or straight out of the spec) to achieve the same result without needing to overload /userinfo. These are currently being explored by FASP, such as standard and custom token exchange, and scoped-down tokens that may return the visa claims directly.

I'd suggest we better understand the limitations of these other standard approaches, perhaps with modest "OIDC discoverable" extensions if the need warrants it, before proceeding with anything as foreign as overloading /userinfo to produce access tokens. Overloading /userinfo is not the direction additional specs are moving that build on the original OIDC and OAuth 2.0 specs to handle specialized tokens.

[davidbernick]

Ok -- this is a good discussion. Because this WAS discussed for several "real world" reasons, we can leave it as is, and instead I'll make an FAQ or "use-case" section that will be supplanted when we (presumably) offer a /token endpoint that makes this moot.

The issue came up for systems that are not coupled but have agreements in place and if one system's /userinfo spits out a JWT, can that JWT be used on a ClearingHouse as authentication. My take (and intention in the spec) is "yes". I wanted to make that clear. Since a "JWT-as-authentication" is outside of a normal OIDC flow, this caused confusion.

[davidbernick]

ok @cdvoisin and @mikael-linden -- I took your (very good) advice and made this clarification in the (new) appendix section and took it out of the spec. This way we can continue development of key systems like RAS and have their concerns answered while not cluttering the spec. Let me know what you think conceptually -- we can nitpick later.

[mikael-linden]

I'm materially happy with the change but I don't think it is practical to make FAQ an appendix of the spec. FAQs should be quite lightweight and easy to update but specs harder.

[davidbernick]

Sounds good @mikael-linden -- I'll make it a separate doc as a FAQ as opposed to the Spec --

Request opinion here: should i even reference the FAQ from the spec or not acknowledge it?

[mikael-linden]

I don't think a spec need a "Look the FAQ for more information" boilerplate but the FAQ needs to be easy to find.

[davidbernick]

ok @mikael-linden and @cdvoisin -- I moved this info to a FAQ, provided a diagram. I think this will be good for the clarification we keep getting asked about in the field.