Minutes

Attendees: Keith Wessel,  Judith Bush, David Bantz,  Derek Eiler, Joanne Boomer, Marina Krenz, Mark Rank, Matthew Economou,  Steven Premeau, David Walker

Reps from other groups: David St Pierre Bantz (CTAB)

Staff: Albert Wu, Nicole Roy, Andrew Scott, Dave Shafer, Steve Zoppi

Scribe: Eric Goodman, Joanne, Steve P

Browser Changes

  • The FedID community group driving the FedCM API is currently a community group in the W3C. There is momentum to elevate the group to become a more official type of group, a working group, in the W3C. Then only people sponsored by member organizations can participate and the specs become official.
  • I2 joining W3C so we can participate in W3C working groups

Operations

  • Moved to using intermediate cert for signing process (instead of end entity cert) as of today (5/18) per previous TAC approval.
  • FM updates caused some bugs. All resolved now. 
  • Seeking final approval to work with an agency partner to work on BE open items.
  • BaseCAMP in July (get the word out to people who should attend)
    • Tends to be more introductory but technical information about IAM (genearlly), federations and TAP topics. 
    • It’s really for people who are either new to the IAM space, or new to IAM in higher ed, specifically. But, it has great content and opportunities to connect for almost anyone in the space.
    • https://incommon.org/academy/camp-meetings/
    • Q: is basecamp geared more toward iam ops folks, management, or...?

IdPaaS pilot

  • Has identified 8 schools as a pilot group. 
  • This is primarily to provide feedback; mostly these are institutions already using hosted/provided solutions.

REFEDS MFA update

CTAB

  • Mostly discussed Federation Readiness (which is the main theme for the year’s workplan). How to ease onboarding into federation-space. (IAM wise, not Star Trek wise).
  • E.g., “how to” info, guidance support the new entity categories might be an example deliverable. Focus on adoption of standards and best practices. 

CACTI

SAML2Int group updates/discussion

  • Discussed new entity categories, and that operators should  consider their requirements to be essentially “attribute bundles”. So IdPs should be able to release these attributes, and SPs should consider how to develop services around receiving these attributes, even if they don’t use the entity category.
  • Lots of discussion around eduPersonScopedAffiliation and appropriate use. Even the “anonymous” profile requires you to be able to assert ePSA.
  • SchacHomeInstitution: Single valued attribute; how do you express this (as an IdP) with users who are in a sub organization? E.g., at a campus in a multi-campus university system (assert campus vs. university).
  • Pseudonymous discussion also included what use used after the @ sign, especially when an IdP represents more than one home organization. 
    • Publishers typically want to use the domain/IdP to determine who the customer is, but even that is not reliable. 
  • Historically there has been a lot of flexibility in how to implement/leverage eduPerson elements, but the downside of this is that it creates a lot of inconsistency.
    • Possible overlap with the goals of the earlier Badging discussions here?
  • Some suggestions were around “which affiliations” should be used. E,.g., In some use cases it’s possible that we would recommend only asserting “member” or “affiliate” (and not the other attributes). How would this impact signaling? Is this a new best practice?
    • This is guidance both for IdPs (in terms of what should be released) and SPs (in terms of what the expectations should be about data being received).
  • One discussion: Need for a preloaded value (i.e., loaded out of band from SSO login) for library/circulation purposes. One discussion was to use entitlements. The value that needs to be provided would be a fixed/pre-defined entitlement that gets sent in the SSO message, but the SP would be able to know (in advance) what the value would be. 
  • Next up: Personalized Access Category

Work plan progress and planning

  • Middle Things aka Federation Proxies
    • Is this likely to be in a form for TAC feedback by July?
    • Probably yes. Note that this is an informal group, not formally chartered(?) by TAC.
    • Also note, most of the suggestions and issues called out are probably not things for TAC to follow up on. E.g., might be more about communication, visibility, etc. rather than strictly technical implementation details. 
    • May also be appropriate for a community consultation.
      • The Federation should enhance its policies and agreements to specifically address concerns that attach to federation proxies.
      • InCommon should consider a modified fee structure for cost-sharing with commercial federation proxies.
      • Define more precise vocabulary to articulate major concepts, components, and interactions in federated access.
      • InCommon should expand its documentation on best practices for IdPs and SPs to include Federation Proxies.
      • Federation proxy operators should advertise the services they represent (and InCommon should provide a mechanism for doing so).
      • Foster the adoption of (well recognized architectures for) federation proxies (such as AARC)
      • How do you expose (policy/process wise) what is “behind” a proxy, where relevant? Could be relevant to Browser Changes and their intent to require consent at each step, too.
      • Summary of (current) Recommendations under discussion (subject to change)
      • Should Proxies be considered to be a separate “type” of participant?
      • NIST 800-63 Consultation
        • Commentary completed and submitted
        • Report still to come
  • HECVAT
    • This may be the year they revisit, but for now this is there as a “maintenance/potential annual” item.
  • Federation and Digital Wallets 
    • CACTI is taking the lead on this.
  • Federation Testing
    • Is this something that should be on the worklist? 
    • What would we be looking to address on this?
    • Important to Matthew E. and would like to work on that for the second half of the year.

Next Call @ June 1, 2023


  • No labels