Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Open Actions

  2. Administration

    1. Introductions
  3. Schema management - where is work required?

    1. SCHAC
      1. Incorrect SCHAC URN registry values (See schema-discuss@ post from March 25)
    1. eduPerson

      1. FAQ refresh: https://docs.google.com/document/d/17YIEaGotKSGQoGRISgDky_wKelv34xjajgvmyhLjnTs/edit?usp=sharing

        1. Approach as an FAQ update task force; invite others from schema-discuss. Create a series of calls focusing on specific areas. 

        2. Make sure to generalize this more globally (e.g., we can refer to FERPA, but need to explain what it is).

        3. If there are other eduPerson FAQs in other federations, see if any material there might be useful for this. Action: Alan to send links to these other eduPerson FAQs to this group.

          •  

            Heather Flanagan to post a call for volunteers to help with the FAQ to schema-discuss. 

      2. Deprecating eduPersonTargetedID (See schema-discuss@ thread with subject "Deprecating eduPersonTargetedID" from late March)

        1. Request is to edit the schema to include an update that eduPTID is deprecated. See the draft text from Scott Cantor. The attribute can’t be removed—it is too established in SAML deploments around the world—but we can indicate that going forward other options should be used.

          1. https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-id-attr-v1.0.html

        2. Is it the role of this board to suggest an alternative?

          1. Recommendation that came through the REFEDS list are: the following ordered list (1 being the most preferred)

            1. ePUID

            2. urn:oasis:names:tc:SAML:attribute:subject-id

            3. ePPN (if 
eduPersonAssurance=https://refeds.org/assurance/ID/eppn-unique-no-reassign)


            4. ePPN (if IdP supports R&S and if there is neither 
NameID(urn:oasis:names:tc:SAML:2.0:nameid-format:persistent) nor ePTID)

            5. ePPN + NameID(urn:oasis:names:tc:SAML:2.0:nameid-format:persistent)


            6. ePPN + ePTID (if the IdP support R&S and sends ePTID but not as 
NameID)


            7. urn:oasis:names:tc:SAML:attribute:pairwise-id


            8. NameID(urn:oasis:names:tc:SAML:2.0:nameid-format:persistent)


            9. ePTID

          2. This list is indicative of how complicated the issue of what attributes are recommended is in the real world

          3. Suggest we take up the five items from Scott Cantor’s email and make them work items to deal with

            •  

              Heather Flanagan to create the necessary landing page(s) for the work items as described

            •  

              Scott Koranda to populate the landing pages for work items

    1. Publishing schemas in ready-to-use formats for different directory servers

      1. (See refeds@ thread from mid March "eduPerson 201602 in older slapd.conf (eduperson.schema) format?")

      2. https://spaces.at.internet2.edu/display/macedir/LDIFs

        1. Statement: We will make sure that an LDIF is available for the latest version of each schema we manage, based on a single standard LDIF model (check RFCs).

          1. Further consideration - will this LDIF work with AD? Can we get a tool created from within the community to create this LDIF? What about documentation for how to convert a standard LDIF to something AD can consume? Is there actually enough energy in the community to do this kind of thing?

            •  

              Keith Hazelton to propose to the list the most standard LDIF format with RFC justification, and we can discuss from there.

  4. Future schema to consider?

    1. voPerson

      1. This is a schema developed out of work done with some VOs (specifically CILogon) and is designed to supplement eduPerson for VO specific use cases. 

      2. There are still some changes pending to the schema.

      3. According to the Schema Board Terms of Reference: "The Board may decide, after appropriate consultation with the community via the schema-discuss@lists.refeds.org mailing list, whether or not to accept new schema or change existing schema."

      4. What other communities need to be engaged? They should be engaged first. Also, since this is largely housed within CILogon, someone from CILogon should make the official request, and then the board can make the request to discuss list. 

        •  

          Benjamin Oshrin will contact Jim Basney to kick off discussion of moving voPerson from CILogon to REFEDS

  5. Mechanism for issue tracking?

    1. Wiki
  6. Administrivia

    1. Nominating a Chair

      1. Scott notes that the chair should offer a formal reply to Peter Schober and Scott Cantor acknowledging their inputs.

    2. Determining who is serving a 1 year vs a 2 year term

    3. Accepting or changing the Terms of Reference

      •  

        Heather Flanagan will handle the above (chair nominations, 1-2 year terms, accepting/changing the ToR) via email

  7. AOB