Child pages
  • Entity Category Consultation - Personalized Entity Category

Versions Compared


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


comment #Line/Reference #Proposed Change or QueryProposer / AffiliationAction / Decision (please leave blank)
115 & 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
229, 149, and elsewhereMaybe 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
338-41These 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 <mdui:InformationURL>. 
However, these two requirements are not explicitly listed in the following chapter 'Registration Criteria'.
Thomas Lenggenhager / SWITCH
415, 49The 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
590, 89Propose 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
6Section 4.3 or 5.1.1The 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
749-52 and 98-101Understanding 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
853-61Why not making a security contact mandatory - as a  trust-buldling measure?Wolfgang Pempe / DFN
968-70Since 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