Minutes

Attendees: Keith Wessel, Derek Eiler, Joanne Boomer, Marina Krenz, Mark Rank, Judith Bush, Steven Premeau, Eric Goodman

Reps from other groups: David St Pierre Bantz (CTAB), Les LaCroix (CACTI)

Staff / SME: Albert Wu, Steve Zoppi, Ann West, David Walker, IJ Kim, Dave Shafer, Kevin Morooney

Scribes: Joanne Boomer, Eric Goodman

Agenda Bash + request for notable working and advisory group updates

  • Canceling July 13 TAC meeting (concurrent with base camp)

Status Updates - Q&A

EC/SAML2Int group updates / discussion

  • https://docs.google.com/document/d/1B45F1GKHjUY0j3QNlQ_XojFziKN9W02xCuL49vdAQRk/edit
  • This is an early sanity check from the group to see if we are going the right directions and feedback and suggestions you may have.
  • Working on deployment guidance, current is new Entity Categories. Explain how to use attributes first.  Intent is to publish material as we go along.  Asking today to focus on content accuracy and appropriateness.
  • Draft guidance for how we would like InCommon participants how to plan for them, use them, migrate towards them and use it in the context of entity category.
  • Three access categories define a set up attributes for
    • Use as a base template for use with individual SP’s (there is still value in all of use using the exact same attributes)
    • Use for entity category to release to ANY SP’s in those categories
    • Migration is mostly around identifiers
  • Not a lot of clarity on how each party should treat these attributes.  Over time everyone started interpreting these in slightly different ways because there is not clarity.  Let’s try and define it, starting with eduPersonScopedAffiliation.
  • eduPersonScopedAffiliation
    • Question: what are reasonable values to use on right hand side of the @ sign?  Who gets to decide and how should you use it. A: The IdP gets to decide the scope.  Some IdP’s represent multiple institutions. Some SP’s want you to define which unit you are within the school.
    • Discussion: most vendors treat it (validate it)  as you would a certificate.  There is a domain, you request control of users in that domain, and prove control of domain (usually via some DNS mechanism).  Now all email addresses that fall into that domain are controllable by you. Practically speaking, we should probably recommend an approach for IdP operator “scope” management that reasonably aligns with “controlled domains” that most vendors expect.  It would be practical to have email addresses/id’s that work in the different domains, and to have the “scope” management align with how vendors manage domains (though this is counter to how R&E have done it in the past)
    • The guidance in the document is more to the SP’s on what not to expect than to the IdP about what they need to assert.
    • What part of vendor advice is missing (response to Discussion above)? Eric - it’s not explicitly missing, more saying we should be thinking about whether this approach would apply if we also have to assert to vendors like Azure or Box (who rely on “userid domains” rather than “scopes”.
    • More words to say limiting your granularity for a privacy area but will also help you from a vendor standpoint as well.
    • These are all symptoms/elements that speak to how integration is hard.  If we don’t provide guidance or default way of doing things everyone has to find their own way.
    • Question: Left hand side
    • Definitions are not always as clear and have been interpreted differently.  Some has implemented affiliates in a different way that what eduPerson suggests.  Alum fits neither under member or affiliate.  Most prominent part is in Privacy.
    • If you release all affiliates you could potentially identify someone without releasing identifier.
    • Recommendation for anonymous send only Member and Affiliate.  This guidance is not listed anywhere
  • schacHomeOrganization - almost no one in US uses this today.  Some guidance, especially important if you are using international SP’s.
  • Identifiers - OASIS spec - Subject Identifier and pairwise-id
    • Offer a clear explanation on what these identifiers should have been.
    • If your eduPerson values match what these should be, then go ahead and use same value if they are the same syntax.
    • Big Change, some identifiers are explicitly case sensitive, but many people have implemented case insensitive. Even when case insensitive, they are sometimes stored/communicated in ways that are effectively case sensitive (e.g., IdP sends a mixed case “case insensitive” ID). 
    • Change management - how to devise a plan to move from where they are now to where they should be and what life is like in the middle of that movement.  How do we convince SP’s that they need to weather that change.
    • Scoping question apply to these as well.
    • Release documents and a set of blogs and communications
    • What’s next: this group, if you have any feedback send or note inline in the doc.  Otherwise we proceed as described so far.

Wallet / SSI Pre-read

  • Wallets pre-read is a teaser, since we were involved in the conversation.  A good read for everyone and let us know your thoughts and if we should make room for discussion about the thoughts conveyed in the paper.

Email Updates

CACTI Update

from Steven Premeau:

  • Working to finalize the blog posting on on Passwordless Authentication and Password Managers
    • First drafts were started after the LastPass breach notifications... 
  • Discussion of the engagement that has recently occurred between NIST and InCommon/Internet2
  • Finalizing the feedback on the NIST IAM Roadmap draft for submission to NIST
  • Status update on the spin-up of the Next Generation Credentials Use Cases Working Group
  • Discussion of what the eduroam Advisory Community might need to consider / take action on as IEFT plans the depreciation of RADIUS over UDP

Next Call @ June 15, 2023


  • No labels