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
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