DRAFT

Next steps with OIDC

The TAC’s involvement with OIDC/OAuth2 as a protocol for federation (or possibly as a Shib/OAuth2 gateway) was discussed at the 2016 Tech Exchange in Miami. The decision was to spin up a WG to survey the community, and take next steps based on the results of the survey. This Work Plan item is that “Next Step.” What should we do?

Suggestion/Action Item	Submitter	Description	+1s
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?	Mark Scheible	This could be a WG to look at moving forward with a multi-protocol IdP release, resulting in Recommendation(s) to InCommon Ops or TIER TB: Align and integrate this work with REFEDS OIDCre WG rather than doing a separate WG.	Albert Wu Tom Barton Eric G. Mike Grady
Probably should touch base with Roland and any other REFEDS efforts to understand what is currently being done	Mark Scheible	This is a continuation of above item, right?
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> I think we should be focused 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.	Mike Grady	So there are open source solutions today. 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.
TAC Sponsor(s)/Champion(s)		Albert Wu, Mark Scheible, Jim Jokl

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.

Current known scaleable discovery implementations:

Suggestion/Action Item	Submitter	Description	+1s
Identify the gaps/challenges associated with IdP Discovery in the modern, interfederated, per-entity metadata world and create recommendations for gap closure (new standards work, profiling work, new discovery service modalities, etc.)	Nick Roy	Working group, probably at the REFEDS level	Tom Mitchell Mark Scheible Janemarie Duh Mike Grady Eric G.
Identify the dependencies and overlaps related to the per-entity MD work.
Has there been investigation into leveraging DNS to perform IDP discovery (ala MX record for email routing)?	Albert Wu
TAC Sponsor(s)/Champion(s)		Tom Mitchell

Attribute release

The InCommon Federation was founded on a principal of privacy protection (limited attribute release to SPs). This approach may have contributed to very restrictive Attribute Release Policies (ARPs) on campuses (along with Privacy Laws and FERPA). The Research & Scholarship Attribute Bundle was created as a way of assisting Research and Collaboration organizations with getting campus IdPs to release the attributes they need from researchers and collaborators, when accessing their resources with federated credentials. Unfortunately, R&S while a great idea, has not been adopted by nearly enough institutions to make federation “work” for research organizations. This item is more of an Outreach effort to communicate to campuses the importance of having a more open attribute release policy, particularly for those R&S SPs in the InCommon/eduGAIN metadata.

Suggestion/Action Item	Submitter	Description	+1s
Create WG to document and make available persuasive arguments to use with stakeholders resistant to attribute release	Mark Scheible, Nick Roy	Solicit community input and (possibly) work with Steering on this item (* Keith W. has provided such a document to Ken K. - will be posted on CARMA site)	Kim Milford Tom Mitchell Albert Wu Tom Barton Jim Jokl Mike Grady
Input from CARMA work might be referenced
Possibly survey community on why attributes are NOT being released - identify obstacles			Janemarie Duh
Advocate for a required, broad, default attribute release policy for InCommon participants to release some kind of user identifier to all SPs in metadata		TB: Identify what is needed to get to a default InCommon IdP distro that includes R&S attribute release policy.	Tom Barton Jim Jokl Janemarie Duh
Define additional entity categories such as ready-for-collaboration which could be pushed to REFEDS
This is a “get the right stakeholders” involved problem, not a campus IT/technology problem. Identify the needed stakeholder groups, and identify the targeted material, and use cases, that can convince those groups.		Create all the technology solutions and options you want, it isn’t going to solve this problem. Develop the focused materials for why the VC/VP of Research should be pushing for this, why Registrars (and HR, at least at private institutions) should feel comfortable with this, etc. Get lawyers, FERPA experts, NSF/NIH reps, BTAA Senior Research Officers, perhaps (data archiving & data management plans) University Librarians involved in helping to identify and shape the targeted materials for these key audiences.	Chris Misra Janemarie Duh
Be aware of what your attribute release policies are allowing		Actually a bit of the reverse of getting broader release policies in place. Occasionally run into places who have “any” release policies in place that they don’t understand the ramifications of (e.g., no FERPA considerations have been taken into account)
TAC Sponsor(s)/Champion(s)		Mike Grady, Keith Wessel

Federation Interoperability

Build on the work of the SAML v2.0 Implementation Profile for Federation Interoperability to update and extend saml2int and/or propose additional R&E federation-specific profiles that may be taken to REFEDS for review/adoption.

Suggestion/Action Item	Submitter	Description	+1s
Recharter Deployment Profile WG	Mark Scheible	Add additional deployment profile requirements (e.g. Research Profile)	Kim Milford Mike Grady Eric G. (on existing WG… is this different?) - TBD

TAC Sponsor(s)/Champion(s)		Eric G., Keith Wessel, Walter, H.

Improve Community Access/Visibility to TAC (See: InC TAC )

Complaints from participants that would like to see TAC working on specific issues (known concerns from the Research community) or at least visibility into what’s being done, have prompted this Work Item. This is a direct response to the lack of “Openness” by TAC (and others) . From an internal perspective, it’s frequently difficult to find TAC documents or WG information unless you happen to have the link to it. This project will focus on a “temporary fix” that will make TAC work items and additional content more visible to the community, and accessible from a common site. A longer-term solution will align with a future redesign of the Internet2/InCommon web site.

Suggestion/Action Item	Submitter	Description	+1s
Sub-committee of TAC to work on new public-facing site/wiki	Mark Scheible	Work with Dean on making TAC content easier to find, as well as providing a location for the community to comment/suggest on proposed Work Plan items during the planning process.	Tom Mitchell Albert Wu Mike Grady
Develop intake mechanism for comments from participants	Mark Scheible	Can an alias be added to the TAC list address so that Participants can send questions and comments to us? Spam isn’t a concern because of good spam filters.	Janemarie Duh
Hold Community Webinar(s) on TAC Work Planning	Mark Scheible	Either as IAM Online webinar or specific TAC Update webinar	Janemarie Duh
Create TAC-Discuss list for Technical discussions, requests, input from the community, etc.	Mark Scheible	Separate from Participants (all members?) or tac-incommon (private) lists, this will be an opt-in list to obtain feedback, discuss strategies, or allow more direct questions of TAC on specific or potential projects.
TAC Sponsor(s)/Champion(s)		Mark Scheible, Janemarie Duh,

Service Provider (SP) On Boarding

Currently Identity Provider organizations provide testing and onboarding guidance for new service providers. This process has allowed InCommon to scale in this regard, but over time, has contributed to the variability in service provider configurations. It also places undue burden on IdPOs to spend time explaining detailed requirements to new service providers and ensure these new members interoperate accordingly.

The Service Provider OnBoarding activity would explore how service providers are onboarded by IdPOs and make recommendations for services, technologies, and processes for better aligning practices across federation service providers.

As a side note, there are implications on Identity Provider Operators as well as Service Providers. It is proposed that this is out of scope (for now) for this work task.

Suggestion/Action Item	Submitter	Description	+1s
Working Group to collect requirements for SP onboarding with the goal of decreasing variance of their configurations	Ann West	Solicit Community issues, define requirements, make recommendations for how to address.	Janemarie Duh Mark Scheible Mike Grady Jim Jokl (UCLA) - If committee agrees, I’d like to nominate UCLA’s IDM manager to assist with this Tom Barton
Scoping of this effort should be clearly stated in the proposed charter. Understanding the issues (as Ann described above) is probably a bigger task than it seems.	Mark Scheible	It might be a good idea to start with a short-term Survey group (similar to OIDC) to get a sense of the problem, as well as understand what content is out there.	Janemarie Duh Mike Grady
Standardize the vocabulary of technical terms (Mike Grady - question to consider, would this extend not just to technical terms, and the direct IdP/SP integration, but also to provisioning feeds (or API calls) that create user records in the cloud service -- and the vocabulary, field names, etc. that are used to define the CSV-type or API fields? I find the terminology/name of those fields are confusing to campuses versus the attributes they are sending in a SAML response,)	Janemarie Duh	This is needed to get SPs on the same page with IdPs. It will serve to make clear the understanding of any standards and guidelines that are developed and make it easier for IdPs to understand SP requirements.	Mike Grady Jim Jokl Chris Misra
TAC Sponsor(s)/Champion(s)		Janemarie Duh, Jim Jokl, Mike Grady, Keith Wessel,

Page tree

InCommon TAC 2017 Work Plan