...
Suggestion/Action Item | Comments or Elaboration | Name, Organization |
Based on Final Report Recommendations from OIDC Survey WG, charter new follow-on Working Group to address… what? This next step should be scoped based on the survey responses. Will this group be looking at federation solution(s) or a campus gateway? | The OIDC WG recommendations are available here. | Mark Scheible, MCNC |
Probably should touch base with any other REFEDS efforts to understand what is currently being done | See also https://wiki.refeds.org/display/GROUPS/Scope%2C+Activities+and+Planning and for work on mapping attributes to claims and OpenID Connect Federations (Maarten K.) | Mark Scheible, MCNC |
What are the key requirements/features for the software needed to support this, and critically, what is the support plan/funding to provide support for the software? We have software options, what is needed for organizations to be comfortable using it. Focus on the requirements, features/flows needed, OP versus RP, etc., and what InCommon and related organizations like REFEDS are uniquely qualified for, the federation/policy/interop aspects of this, not on the software itself. | The Shib IdP is multi-protocol today (SAML & CAS), and there is an OIDC OP extension for it (https://github.com/uchicago/shibboleth-oidc ). And CAS 5 ( https://apereo.github.io/cas/5.0.x/ ) is an open source product that supports SAML, CAS, OpeniD Connect, OAuth (both as server & client) etc.. etc. (For that matter, WSO2 does also). The key is “can you count on that software being supported, becoming easier to manage, continually developed, adding features, etc." | Mike Grady, Unicon |
| GÉANT has a current project being led by Maarten Kremers to evaluate OIDC federation deployments using Roland Hedberg's draft. TAC should understand the scope of what this GÉANT project is doing and identify any ways InCommon can/should align with either the testing itself, or the outcomes of the testing. | Nick Roy, InCommon | |
| The current OIDC survey results are heavily laden with API and mobile use cases, but the need for OIDC federation is not as strongly emphasized by the responses. The report and/or next working group needs to identify what, if any, priorities the community needs us to focus on first, their relevance for federation, and then how best to proceed. | Nick Roy, InCommon | |
| I think it would be a mistake to ignore OIDC/OAuth activity on member campuses until Federation use cases arise. There's already lots of activity, and it will undoubtedly continue to evolve. | Steve Carmody, Brown University | |
| Nick Roy, InCommon |
...
Discovery 2.0
Current models of IdP discovery depend on a [monolithic] SAML aggregate that allows a discovery service to know about ‘all’ relevant IdPs. In a world where there is no longer an aggregate (or where aggregates are too large for software to realistically work with) there needs to be a way for SPs to get a list of IdPs that meet their requirements, and then to obtain the metadata needed for each IdP the SP needs to make users aware of. Alternatively, some kind of fundamental change in how discovery works - for example being driven by the right side of a scoped user identifier plus webfinger (OIDC discovery model) may be necessary.
...