This Consultation opens on 6th July 2020 at 17:00 CEST and will close on 31st August 2020 at 17:00 CEST.
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: "Authentication Only". 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.
This consultation is 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.
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: firstname.lastname@example.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.
|Line Number / Reference||Proposed Change or Query||Proposer / Affiliation||Action / Decision (please leave blank)|
|01||general||Authentication Only: Seems to me such a category would be|
proliferating an anti-pattern, which would be actively harmful:
Authentication at /any/ IDP at all, combined with no attributes and no
user identity, doesn't mean anything and I'd question whether such
services actually (should) exist.
While some site licenses may be phrased in such a way (that anyone who
can authenticate at the org's IDP is also considered authorised) the
SP still performs authorisation based on the asserting IDP's entityID
(lacking anything else to identify the "site" from) -- which is a
clear anti-pattern: Organisations and SAML entityIDs do not map
cleanly onto each other, i.e., certainly not 1:1. Some organisations
have multiple IDPs (e.g. one per campus), in some regions a single IDP
serves multiple, fully independent organisations (e.g. central
Which is of course why scoped attributes have been created/used for
such use-cases, so that you can authorise based on an (still
not personally identifying) attribute's scope, e.g. *@univie.ac.at,
without tying this to one specific entityID (or managing the
entityIDs allow to assert that at each SP; instead the allowed scopes
are managed in trustworthy federation metadata).
Furthermore, the claim "to support completely anonymous,
privacy-preserving single sign-on" is unattainable in SAML, IMO, as
SAML protocol messages *always* contain technical identifiers of some
sort that allow tracking of the subject in cooperation with the IDP.
So this spec simply *cannot* promise "complete anonymity" as it cannot
prevent the SP and IDP from collaborating in identifying the subject.
(Only where that's impossible by design could one make such claims,
but not with SAML today.)
Based on the fact that "completely anonymous" is not possible with
SAML (only pseudonymous), the names of the three proposed categories
may also need to be reconsidered ("Authentication Only", "Anonymous
Authorization", "Pseudonymous Authorization") since all three offer
pseudonymity at most.
|Peter Schober, ACOnet|
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
|03||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.|
Entity categories are intended to facilitate scalable and preferably automated attribute release. To be able to do so, the specification must be clear and unambiguous, so the implementation, impact and risk of implementing/using an entity category is clear and unambiguous.
I would argue that scenarios where a bilateral agreement is in place always exist and hence does not need mentioning here.
|Niels van Dijk, SURF|
|05||Line 54||Which "agreement" is being referred to here?||Niels van Dijk, SURF|
|06||Line 80-85||This statement (MUST NOT) is not consistent with lines 117 - 123 (SHOULD NOT). Please explain which is leading. |
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|
|07||Line 122||"Doing so sends conflicting messages" - I fully agree with that statement, and hence I do not understand how having this entity category but allowing "bilateral agreements" is not considered conflicting, whereas supporting multiple attribute categories is. Both result in unwanted attribute exchange and impact the usability and credibility of the entity category in a similar way.||Niels van Dijk, SURF|
|08||Line 76||"when supported by their federation assert this in metadata" is that a MUST also? or perhaps a SHOULD?||Niels van Dijk, SURF|
|09||Line 21||"RAEC" - I wouldn't create new terminology and specifically just new acronyms that will confuse people. Just call them entity categories - the "resource access" part doesn't add anything||Nicole Harris, GÉANT|
|10||Line 54||what agreement does this line refer to?||Nicole Harris, GÉANT|
|11||Line 72-74||it is not possible to use CoCo in scenarios where personal data is not being exchanged via attributes. If you really want something like this, require a privacy notice||Nicole Harris, GÉANT|
|12||Annexes||Split annexes out of the specification document and add as supporting documents on wiki||Nicole Harris, GÉANT|