...

Summary

A recent survey confirmed that there is already substantial use of the OIDC/OAuth2 protocols by campuses. However, using these protocols is substantially “less mature” in the higher education environment than the SAML protocols that have been used for the last fifteen years. This working group will bring together current users to develop and propose standard deployment practices in order to improve the likelihood of interoperation “just working”.

...

Today, most of this activity is intra-campus, providing a campus community with easier access to local applications. However, several of the submitted use cases were intra-system (multi-campus systems) and required some form of Federation support. The previous Working Group expected that inter-campus Federated use cases will begin to emerge, and recommended that a follow-on Working Group identify common practices and standards so that interoperation will be easier for the expected inter-campus use cases. (Already the TIER-API Working Group has proposed an approach to API authentication that includes reliance on federated OAuth2 - see TIER API Authentication in a Federated World.) It is not yet clear where the intra-campus, intra-system, and inter-campus uses overlap (and do not overlap). However, Shibboleth/SAML has evolved to directly address all three scenarios, and does so with a single set of solutions. That is the vision of how campus-based OIDC/OAuth2 use might be managed, and how these two efforts (TIER Software development and InCommon) might facilitate that outcome. The recommendations of this Working Group should move us toward that vision, to the greatest extent possible.

...

1. Document above Charter items on Working Group Wiki in an organized manner:

1. Define the scope of this effort.

2. Channels for sharing information (e.g. email lists, wiki pages, and regular webinars)

3. Track and document use cases and lessons learned; Develop and share best practices. Describe how campuses are using these protocols (and which ways of using them that campuses are not using).

4. List areas where organizations would be helped by increased standardization

5. Identify areas requiring more standardization, and facilitate the development of those standards, as required (Work within existing efforts or create new efforts to develop the required standards)

6. Identify use cases that require multilateral federation support

2. Work within existing efforts or create new efforts to develop the required standards.

3. The group should submit a draft status report to the TAC by TechX 2017 (Oct. 15, 2017). This DRAFT should include an initial list of issues and concerns that Higher Ed Federations will have to address in order to provide their members with a manageable framework for using Federated OIDC/OAuth2.

Objectives

Note: unless otherwise noted, this working group is focused on organizations in the Higher Education community.

1. Refine scope
   1. Review recommendations from the previous WG
   2. Define scope for this WG
2. Share information
   1. Collect and share learning materials
   2. Facilitate information sharing among deployers and interested parties
   3. Coordinate with international community
   4. Examples: email lists, wiki pages, conference calls, trainings, workshops, and regular webinars
3. Develop best practices
   1. Document OIDC and OAuth2 use cases
   2. Document lessons learned
   3. Include what is and is not being used
   4. Include software architectures in use including SAML IdPs and proxies
   5. Include native mobile application authentication using SAML and/or OIDC/OAuth2
   6. Consider campus-specific vs. federation-specific
   7. Identify use cases that require multilateral federation support
   8. Develop recommended practices for deployment, configuration, and use
4. Guide standardization
   1. Identify where increased standardization would benefit organizationn
   2. e.g., Map SAML Attributes to OIDC Claims
   3. e.g. map eduPerson schema to OIDC Claims
   4. e.g. develop profile similar to healthcare, iGov, financial
   5. Facilitate related standardization
   1. Work within existing standardization efforts
   2. Or create new efforts
5. Support multilateral federation
   1. Identify issues R&E federations must address to provide federated OIDC/OAuth2
      1. Include metadata, discovery, etc.
   2. Coordinate with GEANT OpenID Connect Federation
      1. https://wiki.geant.org/display/gn42jra3/T3.1A+OpenID+Connect+Federation
      2. Part of GN4-2 JRA3 – Meeting notes include OIDCfed meetings
         
      3. Includes Roland Hedberg's efforts to make OIDC “federation and interfederation capable”
      4. Includes potential OIDC profile for eduGAIN
      5. Includes implementation blueprint requirements
      6. Includes OJOU (OAuth2/JW*/OIDC/UMA) training courses – e.g. November 2017
   3. Coordinate with REFEDS OIDCre working group
      1. https://wiki.refeds.org/display/GROUPS/OIDCre
      2. Includes OIDC Federation; carried out with help from GEANT OIDC Federation (above)

         1. Refers to OIDC Federation draft specification

         2. Refers to OIDCfed test suite

         3. Refers to Roland's federation-aware RP and OP implementations

         4. Refers to Ioannis and Andres federation-aware OP (based on pyoidc)

         5. Refers to Andreas federation-aware OIDC NodeJS library

         6. Refers to Janusz federation-aware OIDC PHP library

         7. Refers to Janne & Henri adding OIDC functionality to Shibboleth

         8. Refers to Herve, Jule and Maarten interviewing federations on plans, requirements, and use cases
      3. Includes SAML to OIDC mapping
      4. Refers to Registration in the IANA JSON Web Token Claims registry
      5. Refers to Report on mapping of the R&S bundle in OIDC
      6. Refers to AARC2
         1. Includes MJRA1.3-Design-for-the-integration-of-an-Attribute-Management-Tool.pdf
            1. Includes SAML to OIDC mappings (§3.2)
         2. Includes AARC2 JRA1.2B – OIDC-based services in research collaborations
         3. Includes AARC2 JRA1.3B – Guidelines for registering OIDC Relying Parties in AAIs for international research collaboration
      7. Referred to by CILogon OIDC
         1. To establish OIDC interoperability profiles
         2. Recommends use of Certificated OIDC implementations
   4. Coordinate with AARC2?
   5. Coordinate with IGTF for Research and e-Infrastructures?
   6. Present to TAC and Internet2 T&I