at 15:30 CEST, via VC.
| Time | Item | Who |
|---|---|---|
| 5 min | Background, why are we here? | Nicole Harris |
| 30 min | Proposal for changes to R&S | Peter Schober / Scott Cantor? |
| 20 min | Abstract Attributes proposal - do we need this and moving forward 2016 REFEDS Workplan - see REF16-4E | Nicole Harris |
| 5 min | Next steps - working group? | Nicole Harris |
Nicole welcomed attendees to the meeting and asked Peter and Scott to give an overview of the current proposed changes to the R&S Entity Category (R&S Clarification Proposal). The following core issues were identified:
Scott explained that the text maintains the distinction between the 2 bundles - what is typically referred to as the "R&S bundle" and the "minimal subset" but provide clarity around what should be supported, particularly in relation to RequestedAttributes. Affiliation remains the only distinction between the two groups - this needs to be maintained if we wish to issue a clarification rather than a new version of R&S.
A further addition that needs to be added is information on naming and format for specific format use to permit application beyond SAML.
Attendees asked for more clarification to be added to section 7 to make it clear that there are 2 distinct bundles.
ORCID is a good example of a current SP that is struggling to work with R&S because of concerns about the potential reassignment of ePPN and have chosen not to accept ePPN as an identifier (although it can be used for display name etc). The biggest concern is around what happens if an IdP decides to no longer be an R&S IdP. This is particularly important because of the longevity of ORCID and the account linking process used. It is pretty rare for an organisation to go backwards and adopt reassignment after having non-reassignment policy but there are no guarantees.
It was proposed that the text could be clarified to say more about the intention of non-reassigned as a long-term notion and that guidance text should be prepared to explain what happens if an IdP chooses to leave R&S (which would effect an SP's interpretation of ePPN values asserted by that IdP).
The use of a monitoring tool for CoCo was given as an example of how entities can be checked for changes (over time) with regard to the categories they publish support claims for. It was suggested that maybe REFEDS could operate such a tool for R&S, possibly building on some pilot tools being prepared for eduGAIN (Attribute Release Check).
Attendees discussed whether or not an SP could be tagged with R&S under the current text. After discussion and analysis it was concluded that the language used in 1.2 DOES NOT preclude SPs that do not accept EPPN as an identifier and to include this would be a normative change to the specification so should only be introduced as part of a v2 change if desired.
Attendees queried whether ePPN should be set aside for a completely different attribute? This might be possible in the future but would definitely constitution a v2 change to the specification.
Nicole asked attendees if they wanted to put effort in to both a v1 clarification and a v2 of R&S. There was generally a desire to work on both a v1 clarification and in a longer term look for a v2. It will be important to prepare text that explains changes to current users. The end goal of the v1 clarification should be to ensure that federations are implementing v1 in the same way. Some work with the implementing federations should be carried out to verify this.
Steven Carmody asked about clashes between entities supporting e.g. both CoCo and R&S. Such entities need to satisfy both categories' requirements individually, there is no Boolean adoption. This puts pressure on the spec-writing community to make sure that the specifications are non-conflicting, which is difficult when they are developed in different environments. The amended R&S version tries to clarify that R&S itself considers Requested Attribute elements in Metadata to be out of scope (for R&S spec purposes), but CoCo can still require this from SPs.
Need to get agreement that this is just a clarification and this will be an important part of the consultation. After discussion on issues relating to SP support for attributes and IdP support of the minimal bundle, it was broadly agreed that this met the requirements of a clarification rather than a change.
If possible, it would be useful to find out if there are any IdPs that do not release the minimal subset.
Nicole asked attendees if it would be useful to propose and set up a specific working group on attribute issues, potentially reusing the attribute-release mailing lists. Attendees were generally in agreement that this was a good idea although there was some discussion on what the scope of this should be that should be clarified in the WG charter.