Minutes
Attendees: Keith Wessel, Judith Bush, Mark Rank, Derek Eiler, Eric Goodman, Joanne Boomer, Matthew Economou
Reps from other groups: David Bantz (CTAB), Marina Krenz, Les LaCroix (CACTI)
Staff: Steve Zoppi, Ann West, IJ Kim, Andrew Scott
Others:
Regrets: Heather F, Nicole R
Scribes: Judith, Eric, Steve P
Agenda insertion:
Welcome to Marina!
Status Updates
No significant OPs updates
Joanne has NIST 800-63-4 Feedback status. The editorial group has completed the feedback form, submission is soon, but time to provide feedback before submission next week. Send comments to Joanne and Tom Barton.
Here's a link to the public draft NIST document. Note there are 4 documents, an overarching doc and an A, B and C. C is the Federation doc. https://csrc.nist.gov/publications/detail/sp/800-63/4/draft
There’s lots of feedback as normative items seemed more informative, and much focus on OIDC at the expense of others. IAL1 requirements had been identical to IAL 2: the requirements were reduced. Much time and effort generating the 77 comments – leaving out more comments.
CTAB listened to Nicole’s presentation on the hackathon, more below.
Workplan: Any objections before publication? None. The 2023 WOrkplan is approved and may be made public.
Proposed Changes to metadata signing
Nicole is not available so postpone until April 20th.
Review deployment profile adoption value statement for approval
Last call we talked about this statement, we are putting it forth for official proposal before we begin publicizing and using it.
Comment and reminder: Alber’s pitch was this would be the start of an area on the InCommon site to collocate and anchor related content.
Mark has no objection. Derek confirms we are agreeing with the VALUES STATEMENT not the NEXT STEPS. Everyone was given sufficient time to review.
Eric reflects that when we put documentation together like this and for NIST we are looking at (1) what would make federation in InCommon work more seamlessly, then there’s (2) we begin looking at security requirements above and beyond the federation itself. THe federation signals, the organizations manage, and finally, (3) vendor products that go down completely different paths. Have DNS, users with EMAIL, populate under contract, no collaboration except with similar contracts. JIRA, OneDrive, so on do not meet our values; should the values statement call out the specific context - just R&E federation - or does it imply an improvement more broadly.
Mark agrees, notes that there are IdP operator audiences - why should I and my organization care? On the service provider side, specifically the vendors who are going to do what they want to do. We don’t have the market influence for the majors, but there are a whole audience of vendors who can benefit from the scaling.
Eric notes a list of Majors that do not comply that have been considered in the last 3 months; product owners don’t foresee the challenges of the new cloud integrations.
Matthew is strategically looking for this document to drive conversations with major and minor vendors: there is some pull. This can give greenfield SAS implementations the vital guidance, underscored by an organization vouching for it. It allows requirements to be stated in grants and contracts.
Matthew notes that some of the problems are tractable, but includes hoops, middleware. It’s a cost. It helps to have a document pointing to concrete requirements. On the service provider side, it would be great to point at profiles that can help give a starting point to the conversation.
Eric & Matthew propose another discussion about standing up some of these systems in the federation - an IAM online? Definitely a TechEX.
Eric wants to know the contexts this can apply; we have varying points of view. Do we need to include this?
Keith suggests we can tweak if clarification needs.
Eric is uncertain he can assert to his management that the deployment profile is critical to implement, given the current vendor experiences.
Derek is in between Eric & Matthew; being able to point at standards and best practices is helpful, even while recognizing the challenges of collaboration with the Majors type cloud systems. Anything like this can help at least to promote the right way. There are plenty of products that – if they want to go to the niche of higher ed and research – this will provide the signals that will help them work with us better.
Ann reflects that this is part value proposition for the organizations, vendors who intend bilateral relationships – some organizations are OK with that – but it is also integration complexity with InCommon.
An example concern: if you build your email address such that they can’t be used as persistent identifiers, interoperation with vendors is terribly challenging. All he can see as far as collaboration is the [vendor] tenancy is identity system is required. Not just Microsoft insisting that all users participate in the identity ecosystem. Having persistent email addresses is counter to our recommended approach to federation, but an IdP that doesn’t provide them is disadvantaged integrating with many SaaS products.
Ann asks, what does the TAC need to do to help get the implementations aligned with R&E values? This is a significant question we need to address. The “enterprise” solutions are spreading, but the monetization model interrupts the collaboration. What can we do to help with that?
This value statement helps us get our house cleaned before we can really influence the vendors (but don’t wait to start with the vendors!)
We have consensus that we can move ahead with circulating the statement and adding content around it.
Update on advisory group joint TechEx session proposal
David shares: TechEx 2023 session proposal draft abstract from CTAB:
(Title) Scalable Trusted Federation
(Abstract) The InCommon Community Trust & Assurance Board (CTAB) and the InCommon Technical Advisory Committee (TAC) have been working on several important initiatives to increase trusted interoperability among InCommon participants.
The first part of this session will describe the progress in these areas to date and how they will benefit scalable federation, including:
- better user identifiers,
- new entity categories,
- completion of Baseline Expectations v2, and
- operationalizing baseline expectations
The second portion of this session will invite broad input on potential next directions to
- increase levels of assurance,
- facilitate interoperability and security, and
- streamline integration of relying parties
- better support for protocol alternatives to SAML, e.g., OIDC.
Come to be part of current and future enhancements of the InCommon Federation.
Proposed speakers at session: Keith Wessel, David Bantz, Jon Miner, Albert Wu, Steven Premeau…[add your name here?]
Derek asks - as we are discussing scaling federation, a question from research is “Where does OpenID connect fit into InCommon. OpenID Connect is cool, why SAML?” Yeah, let’s continue to bring that up - a movement to protocol-agnostic federation
Judith asks if a report from Europe on the OpenID Connect could occur at TechEX – we’ll see if someone might be interested in giving a late presentation.