OIDC Deployment Working Group

[Nathan Dors <>]

The developers of the GÉANT OIDC extension to the Shibboleth IdP have been generous in requesting and responding to feedback about the extension.

I'd like to accelerate clarification on the scope of the initial release by posting the following five question areas to the REFED's oidcre list, all high-level, related to OIDC-OAuth standards.

Potential deployers and Shibboleth IdP operators will have other questions, too, but these high-level questions are important and distinct enough to clarify sooner and separately.

1. OIDC conformance and implementer profiling

1a. Which OIDC conformance profiles will the extension support for certification?

Here are the current profiles (updated June 2018):
http://openid.net/wordpress-content/uploads/2018/06/OpenID-Connect-Conformance-Profiles.pdf

1b. What additional implementation decisions, if any, have been made or need to be made that significantly impact OIDC interoperability or security provided by the extension?

1c. What configuration options, if any, will be supported to allow deployers to control OIDC protocol interoperability or security?

2. OIDC dynamic client registration

2a. Not really sure what to ask here!

There must be some fundamental implementation choices around dynamic client registration,  interoperability and security, possibly also in relation to the Shibboleth's existing concepts around metadata providers and "default" and "unverified" clients (aka relying parties), as well as OIDC's somewhat overlapping concepts of public vs confidential clients.

Note: a related use case might be a campus deploys a popular native mobile app (for iPhone and Android), and the app uses dynamic client registration and then OIDC code flow to verify the identity of the user. How 

3. Will the OIDC extension support the draft OIDC Federation specification?

4. Will the OIDC extension support PKCE (RFC 7636) for the authorization code flow?

5. Support for non-OIDC uses

We've had some discussion (and confusion) around the implementation of the OIDC extension as a more general OAuth 2.0 authorization server. The often used comparison of OIDC 1.0 as "chocolate fudge" and OAuth 2.0 as "basic chocolate" is relevant here: some OIDC-OAuth deployments only need chocolate fudge, while some need basic chocolate, and others want both chocolate fudge and some basic chocolate!

Here are a couple related questions that might clarify the scope of the implementation of the extension for non-OIDC uses.

5a. How does the extension handle requests that do not include the "openid" scope required by OIDC 1.0? The OIDC specification says non-OIDC scopes may be present and should be ignored if not understood. If the OIDC extension is limited to supporting OIDC, then requests that do not include the "openid" scope are likely ignored, and therefore the extension can't be used for more general use case involving API authorization for a variety of protected resources.

5b. Is the extension aware of audiences beyond OIDC clients and itself? ID Tokens must contain an audience value that includes the client_id of the client (aka relying party) that will make use of the ID Token. In some cases, the OIDC extension will also need to know it's own identifier(s), for example to verify that the audience of a JWT request identifies the Authorization Server (e.g. token endpoint URL, userinfo endpoint URL, or issuer identifier URL) as the audience of the request. Similarly, the Authorization Server might need to know the location of its own userinfo endpoint as an audience for access tokens. However, this list of identifiers leaves out a whole different category of other audiences, namely other protect resources. If the OIDC extension is limited to supporting OIDC, then it may not have mechanisms to identify other protected resources as audiences of access tokens.

Those are the five question areas. In drafting them, I've reviewed info in OIDC extension's online wiki and didn't find clear answers. Of course, that might not be the wiki's fault: I may not have looked in the right location(s) and/or I don't have the expertise to understand what I was reading.

Anyway, I plan to post these questions to the oidcre list shortly.

-Nathan