This consultation is open from Monday 20th September 2021 at 17:00 CEST to Monday 18 October at 17:00 CEST
As part of the evolution of the Research & Scholarship Entity Category, the Entity Category Working Group offers a new entity category that focuses on the attributes being released rather than the type of organization requesting the attributes. This stands in place of developing an "R&S 2.0" specification. For more background and a detailed history of this discussions that lead to this draft please see the Working Group wiki pages.
This consultation will be open from Monday 20th September 2021 at 18:00 CEST to Monday 18 October at 17:00 CEST
Participants are invited to:
- to consider the proposed entity category
- propose appropriate changes / challenges to the proposed text, and
- confirm that they are happy that this should be considered as a REFEDS Entity Category.
We would particularly look for feedback on the proposed attributes associated with a person's name. Given the known challenges in supporting naming conventions that are respectful to differing global standards we would seek to ensure that proposed attributes in this area serve the best possible outcome.
|comment #||Line/Reference #||Proposed Change or Query||Proposer / Affiliation||Action / Decision (please leave blank)|
|1||15 & elsewhere|
I'm struggling to understand the use cases where there would be a "need" for personalization. Most of the time I hear about personalization to be a useability/user interface feature - we want to greet this individual by name once they have signed in. Would it be enough to say "I need my users to have a good experience, and personalizing their experience is a key component so I need these attributes"? I could even see an organization showing data that users respond better to being addressed by name. (a demonstration of the need?)
I agree that a specific reason needs to be provided with specific information about how the attributes will be used. But, restricting this to "need" seems to me to be very much in the eyes of the beholder and a potential source of conflict.
|Laura Paglione / SCG|
|2||29, 149, and elsewhere||Maybe I am not making the connection. Use of "personalized" seems like it could lead to confusion. The category is not a personalized attribute bundle, but is used to indicate a standard attribute bundle for personalization (line 122). Would suggest use of "personalization" (or something else) in the entity category definition instead of "personalized".||Mark Rank / Cirrus Identity|
|3||38-41||These lines require an SP to present the service definition to the users at the time they register with the service and that the service definition is referred to in metadata, I guess it is meant to part of |
However, these two requirements are not explicitly listed in the following chapter 'Registration Criteria'.
|Thomas Lenggenhager / SWITCH|
|4||15, 49||The term "proven" concerns me a little. It seems to imply some kind of test or thorough process, and I'm not sure what that would look like. I'd suggest "justifiable" instead. Additionally, do you need to "prove" that you need all of the attributes in the bundle, or does one suffice?||Hannah Short / CERN|
|5||90, 89||Propose to move line 90 after line 81 as lines 82 - 89 solely refer to assurance whereas line 90 again applies to the whole attribute bundle. I do also wonder what "specific conditions" are. Are there examples? Double punctuation in line 89. Reference "REFEDSAF" (line 82) not in reference section. Do we need an (informative) statement, that the authentication assurance (SFA/MFA) is not covered by the EC?||Jule Ziegler / LRZ|
|6||Section 4.3 or 5.1.1||The entity category spec does not explicitly state that SPs must include the signalling defined in [SAML2SubjId] to indicate requirement for subject-id. It might make it easier for deployers if this were mentioned in either section 4.3 or 5.1.1 (alternatively it could go in the FAQ).||Alex Stuart / Jisc|
|7||49-52 and 98-101||Understanding the term 'data minimisation' in the sense of GDPR, we as federation operators would have to check whether the Service Provider actually needs an identifier (in SAML: subject-id) that enables global user tracking. As for our constituency, only a small number (<10) of initiatives or projects would fit into that category. For the overwhelming majority of Service Providers pairwise-id would be sufficient. So why don't leave it to the Service Providers to indicate the required identifier attribute via the Entity Attribute provided for this purpose?||Wolfgang Pempe / DFN|
|8||53-61||Why not making a security contact mandatory - as a trust-buldling measure?||Wolfgang Pempe / DFN|
|9||68-70||Since some IdPs release attributes based on the Requested Attributes listed in SP metadata (rather than ECs), it might be helpful to recommend that Service Providers also tag the required attributes in their metadata, especially if an SP requires additional attributes .||Wolfgang Pempe / DFN|