Endorsement request - EOSC Helpdesk: Architecture and Interoperability Guidelines

In section "8 Adopted Standards" I am missing protocols and standards for authentication. Given that EOSC AAI has developed an architecture for federated AAI to allow access to all services in EOSC, I would assume also supporting services like a help desk will have federated access enabled?

Helpdesk Service uses SAML login and 'EOSC AAI Login'. Service Owner to add further details 

The help desk systems are likely to receive, store and exchange personal data. I would therefore have expected some statements on privacy and data protection (or at least pointers to the principles that will be followed or implemented). 

NB: Service Privacy statement is available here https://eosc-helpdesk.scc.kit.edu/privacy-policy. The document would benefit from contextualising this information, and Service Owner is awaiting information and assistance from the EOSC Data Privacy Group to improve the policy and to create a DPA. Until such time that this is done, service integrations are on hold.

The helpdesk may potentially receive sensitive data, which might contain information about, or may impact security of systems operated within EOSC. I would have expected some statements on how the helpdesk support and implements secure communications regarding these types of information, will e.g. "Traffic Light Protocol" be used, will messages be encrypted if needed?

Zammad supports S/MIME for security of email communication; the Service Owner will liase with the Security Group led by David Groep.

It looks like the EOSC helpdesk is the first entry point for all interactions. Does that mean the EOSC helpdesk will take legal responsibility for the processing of personal data for its own and all connected systems under GDPR?

DPA is required. Further discusions required to respond to this comment fully.  

p4: Response to Community Need: Reding the section, it feels this section does not correspond to the title of this section. It does not describe the community needs, it is more a description of particular features. Having a section describing the  communities is I think good.

p4: High-level … : typo in reseearch -> research

p5: Figure 1: From a high level diagram I would like to see initially more a context diagram including the different stakeholders, as a requestor but also providers in the picture, with the interactions from stakeholders with the helpdesk system. A technical diagram of the helpdesk system is also good to have.

p13: In the section of full integration in the table of required information some examples are missing, for example on mapping scheme, ticket note, ticket state. This looks important. On the mapping scheme I can imagine an example is too much information to be put into a cell, maybe add an reference to an annex or section.

p13: In the case of the full integration I assume server to server authentication is token based or in another way. But in any case, this is not specified.

we perform the integration based on the credentials of a generic user in the third-party helpdesk, I have added this field to the table. 

Response to Community Need section

Could be strengthened to compel users through highlighting the need for the Helpdesk augmentation and solutions it offers over not using it to the end service/resource users. (Flagged in suggested mode in doc comments.)

Examples of solutions implementing this specification section

The final section on use cases could consider highlighting why they made their choice of the various intergation options described and also a figure potentially to compare and contrast/highlight the different benefits. This could help inform new potential guideline adopters. (Flagged in suggested mode in doc comments.)