OIDC Deployment Working Group

[Andreas Solberg <>]

23. okt. 2018 kl. 00:50 skrev Nick Roy <>:

You may have noticed that I talked about API access as a use case in these slides. Torsten Lodderstedt noted that it seems like we need a federation of OAuth 2 Authorisation Servers, and would also need AS discovery, which is a need shared with the FAPI/banking work in the OIDF. He is interested in talking with us about these needs and figuring out if we can collaborate.

Great slides, Nick.

The OAuth federations mostly consists of placeholders in the latest -05 rewrite of the spec. I am very intestering in discussions on the OAuth federation part. I and Roland has mostly focused on making the OpenID part as complete as possible. A base level support for OAuth federations is reasonable to be defined in the spec. Off course the Oauth federation base level profile needs to be extended in order to support all kind of various use cases and environments.

There is placeholders for spec-ing OAuth entities:

https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.3.4

There already exists standards for OAuth metadata. We need to review these, and possibly extend these with federation related claims.

We also need a OAuth specific flow description, like what chapter 8 is for OpenID: https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.8

In this description, we need to decide how to resolve OAuth metadata from the API base URL (or similar), and discuss whether support client regsitration and symmetric credentials, like the one flow with OpenID and / or to rely on assymetric keys.

The Federation API entity listing is supposed to support basic discovery function. If you know a trust issuer, you can ask it for metadata for a specific type of entities, like Oauth resource servers. The same API can be used to list OpenID Providers to list users institutions to choose from.

https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.4.3

Even more interesting than OAuth, is the discussions that will make Oauth redundant, with a more robust trust framework there is no longer need to ask the oauth resource to authenticate the end user. The protected API may instead indicate which trust roots it accepts for authenticated end users, and client may directly insteract with the OpenID Providers and gather the neccessary proof in order to access the protected protected resource. This may include a package of information that proofs the end user identity (idtoken-ish JWT with API as audience, fetched from a token exchange service), an authorization statement and a user consent statement from a user consent service.

I would like to be able to setup API alllowing end user to store and fetch data, and to bring their own ID(provider). And the API would not be in charge of authenticating the end user, but still make sure that data cannot leaf between identities from the different ID providers.

I would like to be able to setup an API accepting any client registrered by eduGAIN to fetch data from the norwegian SIS (student information system) with foreign guest students authenticated with eID in another country.

Andreas