...
ToR and Chair (Heather) - still stuck on ToR (see below)
LDIF with RFC justification (Keith) - RFC 4512, with relevant section 4.1.5. There is a formal definition there for syntax. Keith will continue to work on this and send info to the list.
Administrivia
Handling non-responsive board members - unanimity is required for e-votes; consensus is required on calls. Quorum is half-plus-one
-
Heather Flanagan to reach out to absentee board member
-
ToR status - we do have consensus on this, so will accept the ToR as written
Nominating a Chair - suggest that the Chair role be from one of the people who have a longer term on the board
Creating a recommendation re: identifiers
(From the SC meeting notes 16 May 2019) Identifiers - the discussion on identifiers is actually fairly scattered across multiple lists, and no ultimate direction. Part of the problem is that the loudest voice are not the organizations that actually use the identifiers. Should we get the right people together to get “the right 1-2 logic” on how identifiers should be used?
Step one: an overview and a preferred order
Step two: a recommended profile for using one order (or another) for different contexts
Who should be pulling this together? Schema board? Another WG? SPOG? Suggestion: Schema Board that reaches out to the other interested groups (SPOG, REFEDS, etc) for input. We want a standard recommendations, and then a new R&S that uses the recommended set of identifiers.
Heather to take the SC’s thoughts on the question of identifiers back to the Schema Board
There is a role for this board to play, but concerned about making a recommendation(s) because that broadens the scope too much for this board. This board can say “here’s what we know about the identifiers and the life cycle of these identifiers; we concur that ePTID have these issues”. But we should not go so far as “here’s how deployers should use these identifiers."
where should this recommendation come from?
this group can input into a discussion of these identifiers; expect that eduPerson identifiers will be lower on the list than the new SAML identifiers. There will be 3-4 different priority lists.
We should be clear on what the buckets are, but how they are used should be out of scope for this board, and in groups that are closer to what’s going on with various efforts.
If a bucket is called “identifier” then what those people should think about it other than “it’s an identifier” If we define the elements and syntax, we say what it can be used for. There is not enough knowledge out there on how to use the schema. Who should be helping them?
Where to draw the line: in the example of ePTID and SubjectID - we know that there is an issue with ePTID and case folding for some SPs. We should comment on that. Because of that, we are deprecating it, and it will be removed from the schema at some point. We should also comment on the SubjectID to make sure people know it’s there. But we won’t manage the change for people, just indicate that it is going to need to happen.
What we might do as a board is trigger a discussion on a larger scale; if we don’t lead the discussion or help wrap up the existing discussions, but we shouldn’t do more than that.
Nothing is stated that ePTID has problems and shouldn’t be utilized. If nothing else, we need to do make that clear in the eduPerson documentation.
Where do we go after ePTID is deprecated and removed? What direction do we give. There are local option and SAML spec options; and institutions would get rid of local options when they federate (local options won’t be recognized in eduGAIN).
Keep the specs in one place and the observations in another are going to be too fine a point since there is no other obvious home.
If we do make a recommendation of moving away from ePTID and moving towards SubjectID and pairwiseID, we would need to understand the lay of the land for software support. We know that Shib can generate and use the Subject and pairwise ID. Unclear as the state for simpleSAMLphp.
Scott Koranda will follow up on simpleSAMLphp. Miro will assist.
Review of Schema Board Work Item Portfolio
eduPerson FAQ update - volunteers include: Peter Schober, Warren Curry, David Bantz, Nick Roy, Raoul Teeuwen, Peter Gietz
Process for resolving work items: Board to review the items and come to consensus on whether the proposal should move forward. If yes, then that is noted in the wiki and a call for public comment will go out asking people to respond by a certain time.
-
Heather Flanagan to create a working draft of the eduPerson spec (OLD/NEW red lined version for the Board to react to; Google docs in suggestion mode). Do this with Work item 1 initially to make sure the process is solid.
-
Work item 1: Change the opening paragraph in section 1.2 before the "glossary" style portion discussing identifier concepts to the following (it splits the text apart and inserts a discussion of protocol specific IDs in the middle)
"It may often be reasonable to map usage of eduPerson identifiers into a protocol, but there may be subtle differences to account for in doing so.” Point to the WG that is doing the mapping of eduPerson into OIDCre as an explicit example of a group wrangling with those subtleties.
-
Scott Koranda will propose text to clarify the proposed text from Work Item 1 that starts with "It may often be reasonable..."
-
Hold off on additional work items until we make sure the process is sorted
Benn has discussed the transition of voPerson to this Board with Jim Basney. Jim is supportive.
Proposed action: charter a subcommittee, charged with developing voPerson 2.0.0 and resolving the noted issues in GitHub. The voPerson 2.0 draft would be the one formally adopted by REFEDS.
No objections to chartering a subcommittee.
Benn will lead the subcommittee; Terry Smith, Alan Buxey, Niels van Dijk have expressed interested.
...