...
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 IDP-style federations). 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 | |
02 | 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 | |
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. | |
04 | general | 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 | |