Attendees

Pre-reading

Agenda

  • Draft: Attribute Specification review

  • Draft: Best Practice guidance
  • schacGender deprecation

  • Next steps

    • volunteers to write a blog post?

Notes

  • Introductions
    • Jon Miner (U. Wisconsin) - helped organize sessions at Internet2 ACAMP on this topic
    • Etan Weintraub (John Hopkins) - working with Shibboleth and LDAP schema for a long, long time
  • Draft: attribute specification review
    • Do we standardize on the separator? Or do we say we're using slash as an example as the delimiter?
    • The intent is that a human reads and understands this, so perhaps better to either take slash out or use more examples with other separators?
    • There is a risk of being too general with our guidance; need to find a balance.
    • The argument for having a defined delimiter will actually make it easier for humans to read the results. Also, from a technology side, it makes it easier
    • If it's multivalued (and it is in the current draft) then a delimiter becomes a sequencing indicator.
    • Should this be multivalued? One argument is no; alternatively, the different values are for different languages. We don't know how the SP would actually import the multiple values - would it pick one at random, or would it consume all of them?
    • Poll: should the attribute be single valued or multivalued? 5/7 = single; 1/7 = multi; 1/7 = need more info
      • How are multiple languages handled? there should be a single value string
      • Should we use the LDAP attribute options for languages? that would support different attributes for different languages; it would be one attribute with multiple values, and different identifiers for each value. Being able to support this and assign the right identifier to the right value is actually the responsibility of the interface. The problem is that most applications don't support LDAP attribute options correctly. This may be something that goes in our Best Practice guidance
      • See https://datatracker.ietf.org/doc/html/rfc2596
      • if this is only supposed to be human-readable, then there's no reason to support multiple values. People can put in there whatever they want. Given the poor support for LDAP attribute options, this might make the most sense.
      • We're trying to avoid complicating the implementations by indicating too many options
    • What about caseExactMatch? It should definitely not be an exact match; one suggestion is that this shouldn't even be searchable. Is the EQUALITY field required? No; we're going to remove
    • Consensus review:
      • this should be a single-valued attribute
      • this should be human-readable; machine readability is out of scope
      • multiple languages are at the discretion of the end-user; we will not be including LDAP attribute options to tag language to values
      • EQUALITY field will be removed
    • Next steps:
      • Heather and David to update attribute specification text
      • Heather to send out a doodle poll for the next call
  • No labels