| Info |
|---|
This Consultation is now CLOSED. |
Background
The Seamless Access Entity Categories and Attribute Bundles Working Group has approached REFEDS and asked if it will become the custodians of a proposed new Entity Category: "Pseudonymous Authorization". As per the REFEDS Consultations guidelines, the REFEDS Steering Committee has reviewed and accepted that this proposal meets the criteria for a REFEDS Consultation. We are therefore opening up a consultation period to invite comments and questions from the REFEDS Community.
Please note the proposed URI would be changed to a URI within the REFEDS domain space if this category is accepted.
Overview
This consultation was open from: Monday 6th July 2020 at 17:00 CEST to Monday 31st August at 17:00 CEST
Participants are invited to:
- to consider the proposed entity category
- propose appropriate changes / challenges to the propose text, and
- confirm that they are happy that this should be considered as a REFEDS Entity Category.
| Info |
|---|
The document for the consultation is available as a Google doc in Suggestion mode or as a pdf attachment. All comments should be made on: consultations@lists.refeds.org, added to the google doc as a suggestion or added to the change log below. Comments posted to other lists will not be included in the consultation review. |
Change Log
| Line Number / Reference | Proposed Change or Query | Proposer / Affiliation | Action / Decision (please leave blank) | |
|---|---|---|---|---|
| 01 | general | As an editorial comment I'd suggest avoiding all the "For the purposes Supported in google doc comments | Peter Schober, ACOnet. Nicole Harris, GÉANT | |
| 02 | general | note that none of the 3 specs mentions NameIDs which are not attributes (and so do not fall under the local -- and somewhat circual -- definition of "user attributes": "a user attribute is *an* *attribute* that [...]"; my emphasis) but are personal data and suitable to identify the subject, in cooperation with the IDP, or even without, depending on the NameID format, nonetheless. So that seems like a significant omission | Peter Schober, ACOnet. | |
| 03 | lines 61, 62, general | As mentioned also with "Authentication Only" comment 04, I do not see the added value of bringing in bilateral agreements. It only weakens the spec, and there is no need because bilateral agreements can always be made. | Niels van Dijk, SURF | |
| 04 | line 92 | Why is the thing now called "Organizational identifier" as compared to the Anonymous Authorization specification where it is called "Organization". I would suggest to harmonize concepts between specfications | Niels van Dijk, SURF | |
| 05 | line 91 -93 | "Organisation identifier", especially if provided in the form of eduPersonScopedAffiliation, is in many cases already a very usefull and likely enough to manage authorization. What if the service has no need for additional roles/groups being provided via the currently required entitlement(s)? I would suggest to state either Organizational or Entitlement MUST be provided, where both MAY be provided | Niels van Dijk, SURF | |
| 06 | line 105-106 | It is bad practice to send empty attribute statements, so how to combine the mandatory entitlement as per line 91 with the statement in these lines where it might be that no entitlement data is relevant to the SP? Also see (05) | Niels van Dijk, SURF | |
| 07 | line 96.3 | Which schema does the memberOf attribute come from? | Niels van Dijk, SURF | |
| 08 | line 111 | Given the aforementioned lack of support for pairwise user identifier, I would word this as " Identity Providers are advised to add support for to the new pairwise identifiers as soon as practicable." As that is much easier then waiting until all your connected SPs have migrated | ||
| 09 | line 116 | Why not (very strongly) suggest using edupersonentitlements for the purpose of metrics? While the value of ePTID needs to be commonly agreed upon by SP and IdP to be meaningful, now at least we can get away from inventing new attributes for metrics. | Niels van Dijk, SURF | |
| 08 | line 130 | "when supported by their federation assert this in metadata" is that a MUST also? or perhaps a SHOULD? | Niels van Dijk, SURF | |
| 09 | line 174 | Using normative wording in implementation guide conflics with normative wording in core document. I would suggest to remove RFC2119 wording from the implementation guide so it is clear that is not normative, but informative. | Niels van Dijk, SURF | |
| 10 | line 253 | I am missing any wording on ePPN here. Is that on purpose? eduPersonUniqueID has teh same propperties as the pairwise id. Perhaps explain why that is not reccomended? | Niels van Dijk, SURF | |
| 11 | section 4 entitlement data | Entity categories are intended to facilitate scalable and preferably automated attribute release. eduPersonEntitlement, isMemberOf and MemberOf are attributes whose values should from a security perspective only should be presented to the intended services. Due to this the attribute release of these three attributes should be configured outside entity category release mechanism. | Pål Axelsson, Sunet |