Rapporto sui risultati

d’identificazione. Il termine «holder of the token» fa pensare che le procedure senza token siano di fatto vietate. Il termine «token» deve pertanto essere sostituito con «authentication factor» secondo l’ISO 29115. Dalla descrizione del TOE sembra risultare che vengano ammesse solo le procedure basate su IdP. Ci si chiede cosa avviene delle procedure che non necessitano di IdP. Il TOE deve essere formulato in modo tale da descrivere la procedura di autenticazione e quella attraverso IdP. Viene infine introdotto il termine «Context» che non è pertinente nell’ambito dell’autenticazione. L’autenticazione deve verificare che l’identità dichiarata sia corretta, mentre il contesto è una questione di autorizzazione. Non rientra nel campo di applicazione del presente documento sapere se l’Identity Provider necessita di tale contesto per scegliere la procedura di autenticazione più adeguata. Il riferimento al contesto deve quindi essere stralciato o considerato facoltativo. Riguardo al numero 1.2.2, SCH ritiene molto dettagliate le spiegazioni sul workflow per l’autenticazione, mentre viene descritto solo l’IdP-initiated Approach. Dovrebbero essere i produttori di applicazioni per la cartella informatizzata del paziente a decidere quale workflow preferiscono per l’autenticazione, IdP- o RP-initiated Approach. Anche i protocolli fra Relying Party e IdP nonché le procedure di autenticazione dovrebbero essere regolati dal mercato. Sarebbe inoltre più semplice per l’utente navigare prima sul portale della cartella informatizzata del paziente ed effettuare successivamente il login. Questo modo di procedere corrisponde meglio alle aspettative di molti utenti e aumenterebbe l’adesione del pubblico alla cartella informatizzata del paziente. SCH chiede di eliminare l’IdP-initiated Workflow per l’autenticazione. Si dovrebbero stabilire solo i presupposti e i risultati dell’autenticazione e non descrivere i passi per raggiungerla. SCH propone: Electronic identification means comprises one or more token that are secured by a device. Each token may hold a credential, that is used by the IdP to authenticate the user’s identity based on possession and control of the corresponding token. An IdP-initiated or SP-initiated approach may be used.

1.5 Assets

Posta segnala riguardo alla tabella 1 che le descrizioni sembrano autorizzare solo le procedure basate su smart card. Se non si modifica questo punto, non sarà più possibile avvalersi del mTAN o di altri mezzi senza smart card. Si richiede di riprendere le definizioni dell’ISO 29115, capitolo 3.3. Posta aggiunge riguardo al numero 1.5: - Public keys by definition are public and they need to protection. È chiara l’intenzione, ma la formulazione è sbagliata. Proposta: Term to be used here is «private keys».

- The expectation in the example of «identification data» is not tenable. Using a combination of attributes to uniquely identify a user seems like a bad choice. Please note that GLN is an extremely dangerous example: GLN is unique for a person. Unfortunately in the health care system of Switzerland we have quite a number of health care providers that work in different organizations that may or may not be members of different communities. Depending on the context of the person, this person may have different users (at least one in each community). È una questione puramente terminologica. Proposta: use proper terminology. Use good examples.

- Table 1: Assertion Data: SAML assertions are the only supported standard to transport claims about the authenticated identity. This is geared towards SOAP web services and not practical for HTTP based services. Se non si modifica, risulteranno problemi con l’integrazione di nuovi profili FHIR IHE e dispositivi mobili. Proposta: Support for HTTP based services should be included.

- There are several references in the document to the purpose of login to a web portal. This precludes purposes like authentication of web services, REST interfaces or mobile applications. Proposta: The purpose should be formulated openly. Further references should be avoided.

- Table 1: The following description is not an «English» sentence; «The IdP stores enough information about the authentication means of the user to validate the user». The IdP must ensure that the information stored about the authentication means of the user cannot be used to recover the authentication means itself. Proposta: change the formulation.

1.6 External Entities and Subjects

Posta dichiara riguardo alla tabella 2 al numero 1.6: - The term «identification token» has not been used before. The term identification means of identification token should not be used. The purpose of this token is to be used in the authentication process and it should be called authentication means. The term