March 12, 2019 – This document includes the working group charter for the period ending in 2018. In 2019, the working group refocused on more specific deliverables. The Objectives section wasn't part of the original summary and charter, but it has been added because it helped define the activities and coordination of efforts for the same period. |
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”.
The last several years have seen broad adoption of two different cross-domain authentication frameworks and their associated identity spaces. Higher education worldwide, a growing number of business systems (especially cloud-based), and groups particularly concerned with security have adopted the SAML protocol and profiles and associated infrastructure (e.g., metadata describing participants). More recently, personal web use and a growing number of apps that are of interest to the higher ed community are using the OIDC/OAuth2 protocol and frameworks. Today, using these protocols requires two different identity spaces (identifiers, credentials). The growing use of OAuth2 to protect API endpoints by higher ed has increased the interest in bridging these spaces, and providing a single software package supporting multiple protocols. This is expected to provide better security, improved usability, and better interoperability in a multi-protocol world.
The report from the recently completed OIDC/OAuth2 Survey Working Group, confirmed that there is already a high volume of campus-based activity exploring the use of the OIDC-related protocols, and particularly OAuth2. That report identified three trends driving this interest:
The adoption of API-centric application architecture - organizations need to enable end-to-end authentication and authorization between SSO-enabled web applications and the APIs behind the applications.
Native (mobile) application deployment - campuses are deploying native mobile applications seeking compatible authentication and authorization solutions for native applications accessing campus resources (usually in the form of API).
Social and SaaS platform integration - organizations either need to support social identities in their applications, or need to integrate campus SSO with Social/SaaS applications that only support OIDC/OAuth.
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.
The previous group recommended a number of next steps. This Charter is derived from their recommendations. This Charter specifies a number of Work Products. They are related (they all have to do with OIDC/OAuth2), but in most cases they are not dependent on each other. It is hoped, therefore, that work can progress in parallel on several of these items, rather than addressing the items in a sequential manner within the “working Group as a whole”.
Review recommendations from the previous WG and determine what is In Scope (and out of scope) for this WG. This should pay particular attention to what was determined to be campus-specific (TIER/CACTI WG?) vs. Federation-specific.
Create channels for sharing information within and from the existing Higher Ed OIDC/OAuth2 deployers and interested parties. The international Higher Ed community should be asked to participate. This could include email lists, wiki pages, and regular webinars.
Track and document the lessons learned; develop recommended practices for deployment, configuration, and use. Document the software architectures campuses are currently using to provide OIDC/OAuth2 services.
Report on the ways campuses are using OIDC and OAuth2. This includes identifying those aspects of the protocol definitions that campuses are not using.
Work with the organizations that are currently implementing these use cases to identify areas where organizations would be helped by increased standardization (e.g., use of OIDC claims, development of deployment profiles, etc.).
Work within existing efforts or create new efforts to develop the required standards. New efforts might be created within existing standards bodies (e.g., I2 T&I, REFEDS, Kantara, http://openid.net/ , etc.)
Develop or adopt a higher education deployment profile for OIDC/Oauth (e.g., profile similar in concept to the one for healthcare: http://openid.net/wg/heart/)
Ensure the development of a Higher Ed attribute schema for OAuth2 claims (i.e., map eduPerson schema to OIDC/OAuth compatible format, likely in JSON Web Token forms), possibly by participating in the current European effort: Mapping SAML Attributes to OIDC Claims.
Track (and possibly participate in) the GEANT OpenID Connect Federation task chaired by Maarten Kremers. This effort includes Roland Hedberg's efforts to develop an OAuth federation framework.
Develop and share information about best practices with native mobile application authentication using SAML and OIDC/OAuth2.
Identify use cases that require multilateral federation support, and bring them forward to the TAC and Internet2 T&I.
Document above Charter items on Working Group Wiki in an organized manner:
Define the scope of this effort.
Channels for sharing information (e.g. email lists, wiki pages, and regular webinars)
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).
List areas where organizations would be helped by increased standardization
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)
Identify use cases that require multilateral federation support
Work within existing efforts or create new efforts to develop the required standards.
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.
Note: unless otherwise noted, this working group is focused on organizations in the Higher Education community.
Refers to OIDC Federation draft specification
Refers to OIDCfed test suite
Refers to Roland's federation-aware RP and OP implementations
Refers to Ioannis and Andres federation-aware OP (based on pyoidc)
Refers to Andreas federation-aware OIDC NodeJS library
Refers to Janusz federation-aware OIDC PHP library
Refers to Janne & Henri adding OIDC functionality to Shibboleth