...
| 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 56, 57, 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 85 - 87 | "Organisation", 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 | |
| 05 | line 98-99 | It is bad practice to send empty attribute statements, so how to combine the mandatory entitlement as per line 87 combined with the statement in these lines where it might be that no entitlement data is relevant to the SP? Also see above in (04) | Niels van Dijk, SURF | |
| 06 | line 96.3 | Which schema does the memberOf attribute come from? | Niels van Dijk, SURF | |
| 07 | line 116 | "when supported by their federation assert this in metadata" is that a MUST also? or perhaps a SHOULD? | Niels van Dijk, SURF | |
| 08 | line 155 | 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 | |
| 09 | line 34-35 | do we have examples? i'm struggling to think of any collaboration tool that does not need personal data | Nicole Harris, GÉANT | |
| 10 | line 42 | use specification not document | Nicole Harris, GÉANT | |
| 11 | line 39-41 | the term user attribute is defined then only used in the definition. Why not use an existing term like personal data? I wouldn't associate user attribute with this definition | Nicole Harris, GÉANT | |
| 12 | Definitions section | for a clear and concise entity category, the definition section should only focus on the definition of the entity category itself. The many definitions are making the document quite lengthy. Why not simply refer to the definitions in eduPerson? | Nicole Harris, GÉANT | |
| 13 | General | either use the full terms for IdP or SP consistently or add these in brackets to the first instance then use the abbreviation consistently | Nicole Harris, GÉANT | |
| 14 | General | why is this category styled as anonymous-authorization where as the pseudonymous one does not have the -authorization as part of the syntax? | Nicole Harris, GÉANT | |
| 15 | line 67 | don't use the word typically - i think this introduces lack of clarity as to how this gets tagged. It's either self asserted or not, and then there needs to be a process for not | Nicole Harris, GÉANT | |
| 16 | line 71-72 | i don't think this sentence is needed in a specification: ' They may need to consult with other departments within their organization to verify the relationship with the Service Provider." it doesn't have any bearing on the spec itself. | Nicole Harris, GÉANT | |
| 17 | line 93-95 | This is explanatory text that has no bearing on the specification itself, it is just a fact of identity approaches. Move as much explanatory text outside of the specification into supporting documents. | Nicole Harris, GÉANT |