...
| comment # | Line/Reference # (please indicate which document is referenced too - e.g. EC line 1, BP line 1) | Proposed Change or Query | Proposer / Affiliation | Action |
|---|---|---|---|---|
| 1 | 6 | I find the opening line a little confusing since the service provider may choose to commit to more rules than just the ones in this framework. "This Code of Conduct sets the rules that Service Provider Organisations can commit to when they..." -> I would suggest a slight change to "This Code of Conduct defines a set of rules that…" | Hannah Short/CERN | |
| 2 | General | Since the Code of Conduct is really about expressing compliance with GDPR I wonder whether the title of the entity category and framework shouldn't be clearer and refer to the fact that it's about GDPR and not a more general Code of Conduct? | Hannah Short/CERN | |
| 3 | EC - 80 | "the registrar MUST at least: ... 7. Ensure they have an appropriate administrative contact that is aware of the Service Provider’s commitment to the Code of Conduct." "they" points to the registrar. Is it the intent the registrar has an administrative contact? | Niels van Dijk (SURF) | |
| 4 | EC - 66/77 | What if the "check" fails? What is the difference between "ensure" and "check"? | Niels van Dijk (SURF) | |
| 5 | EC 62 | Does a RA have the right to revoke registration? If so should that be mention in the document? | Niels van Dijk (SURF) | |
| 6 | EC 74 | Explicitly reference chapter 5 here? | Niels van Dijk (SURF) | |
| 7 | EC 74/77/87 | If registration criteria #3 already mandates accordance with 5.5.1, why is registration criteria #5 still needed? | Niels van Dijk (SURF) | |
| 8 | EC 93/94 | MUST clause in 5.1.4 , why? If the entity is only for intrafederation use , eg only Spain or Germany then why put such a clause? maybe MUST is required if exported into eduGAIN ? | Alan Buxey/independent | |
| 9 | EC 85 | Do we also need a metadata requirement for the Registrar/federation? - their tooling needs to support this entity category | Alan Buxey/independent | |
| 10 | EC 98 | Theres an implementation clash with CoCo and entity category attribute bundles (eg R&S) - the best practice states data minimisation and only request what you need (BP 134) but R&S and other authorization entity categories have values that may be optional. This section in EC states that 'RequestedAttribute' MUST be used for those required - suggesting theres an implementation required that if such values exist and CoCov2 asserted then a CoCo IdP should ignore the R&S and only release the values requested..... IdPs in other jurisdictions or that do not follow CoCo just honour the R&S . if so, this should be explicitly stated. | Alan Buxey/independent | |
| 11 | General comment for EC and BP | It is understood that it is not mandatory to assert or fulfil this EC, and it is understood that information is provided at a national level (and therefore this information will be made available to the SP nationally) but perhaps it would be a good opportunity to include within the best practice additional information the benefits of asserting and fulfilling CoCo, and the implications of not doing so | Michelle Williams (GEANT) | |
| 12 | EC - General | Should it clearly state that v1 is to be deprecated and refer to the fact that it is up to each federation to annouce its intended timelines for deprecation? Should it also position the fact that the national federation will define the rules for the transition? | Michelle Williams (GEANT) | |
| 13 | EC - General | There is no clear guidance on the rules and the subsequent consequences of how 3rd countries outside the EU/3rd countries with adequacy agreements should behave. That is, as an SP in a 3rd country is not entitled to assert CoCo, what are the consequencies if, for example, the services becomes the subject of the 3rd country (via a company takeover or IT outsourcing decision) subsequent to initial registration? It is understood that it's the RA asserting the EC at the request of the SP, and that checks will be made at the point of registration, however it's not clear what the ongoing mandatory commitments of the SP are, i.e., that they must continue to demonstrably fulfil the requirements of CoCo or the SP must immediately inform the RA in the event that they no longer fulfil the requirements. | Michelle Williams (GEANT) | |
| 14 | EC - 23-25 | There is no explicit statement that confirms that SPs outside this scope are not entitled to apply to assert CoCo | Michelle Williams (GEANT) | |
| 15 | EC - L43 - 47 | There is no explicit description of how changes to the use of the data subsequent to its original registration might impact the SP's right to assert CoCo in the future. i.e., the SP might be in scope for CoCo when the SP is registered, but the business might change after registration to the point where the SP no longer meets the requirements for CoCo. How does a SP or RA ensure that it still complies to the requirements of CoCo, and what obligations do the parties have to ensure that is the case? The RA commits to checking at registration, but commits to subset of regular checks, perhaps it could be made clearer that it is the SP's responsbility to ensure that it continues to comply and that it is the SP's responsibility to flag if they no longer comply. | Michelle Williams (GEANT) | |
| 16 | EC - L54 | Should explicitly state v2? | Michelle Williams (GEANT) | |
| 17 | EC - L59-61 | Should it be made clearer here (or in the best practice) that an IdP isn't bound or obliged to release the requested attributes? | Michelle Williams (GEANT) | |
| 18 | BP - L72 | ‘can commit to’ – should be must (I can, but I choose not to) – ‘the measures that the service has employed and commits to’ | Michelle Williams (GEANT) | |
| 19 | BP L117-119 | if I understand the intent correctly, it might be better to simply state “Service Provider Organisations may manage and register several independent Services, however, those doing so are asked to commit to the Code of Conduct for each Service separately” | Michelle Williams (GEANT) | |
| 20 | BP L134-136 | How is ‘access to the service’ defined? | Michelle Williams (GEANT) | |
| 21 | BP L205-206 and Section O | There is no effect of termination in the event of c. i.e., the SP should request removal of the EC, but it’s not set out here or in 524-532; options for termination are not useful if there is no explicit effect of that termination | Michelle Williams (GEANT) | |
| 22 | BP L301 | remove ‘is’ at end of line | Michelle Williams (GEANT) | |
| 23 | BP General | The effects of non compliance aren't explicitly clear | Michelle Williams (GEANT) | |
| 24 | BP Section F | Quite possibly too descriptive: without understanding the nuances of the service's use of PII, it might not be advisable to make statements that paraphrase an understanding or perspective of the regulations; perhaps only the relevant sections of the regulations should be referred to here? | Michelle Williams (GEANT) | |
| 25 | BP Section J | Standard contract clauses' should be 'Standard Contract Clauses' and a reference should be provided. | Michelle Williams (GEANT) | |
| 26 | BP Section L | Perhaps this should instead refer to all parties holding the authors of the Best Practice harmless? GDPR has specified liaibilities that might be dangerous to paraphrase here | Michelle Williams (GEANT) | |
| 27 | EC section 5.2.1 | If the SP conforms to the subject identifier profile, then it has to signal the requirements as per the profile, so it's arguable that the section is extraneous. However, you obviously want to say something about subject identifiers (as they're personal data, after all). Note also that the text itself is somewhat confusing 1) an SP can conform to the profile and signal that it does not require a subject identifier, so it can't indicate which one of the identifiers is necessary, because neither may be 2) how you refer to the entity attribute isn't clear. Therefore, I think the section needs a rewrite. | Alex Stuart (Jisc) |
...