Guidelines for the LSS for NemID interaction design and user selection

Transcription

1 Guidelines for the LSS for NemID interaction design and user selection Table of contents 1 The purpose and audience of the document Introduction Recommendations Visual appearance Sizing Internal error handling Help messages Certificate selection Remembering user name Presenting text to sign Presenting text to sign in PDF format Printing mechanism for signing document Download of pdf documents to be signed Accessibility Signaturgruppen 4/ Page 1 of 10

2 Version history 4th April 2014 Version 1.1 MSP 28 th March 2014 Version 1.0 MSP 13 th March 2014 Version 0.91 BS 2014 Version 0.9 JGB Signaturgruppen 4/ Page 2 of 10

3 1 The purpose and audience of the document The purpose of this document is to provide guidelines for the interaction design, in order to make the design recognisable to the user. The document addresses the personnel of the service provider, responsible for designing the user experience and graphical user interface for online services. Summary of all documents in the LSS for NemID service provider package: General documentation Introduction to the LSS for NemID service provider package Guidelines for the LSS for NemID interaction design and user selection Terms and concepts in LSS for NemID Implementation documentation General technical specification Implementation FAQ for LSS for NemID Test documentation Guidelines on the use of LSS for NemID test tools Recommended test procedures for LSS for NemID Reference documentation Specification document for the PID-CPR service Specification document for the RID-CPR service Specification document for LDAP API Specification document for OCSP Specification document for OCES II Signaturgruppen 4/ Page 3 of 10

4 2 Introduction The classical user scenario for using NemID for business (key file) includes a list of all the certificates installed in the certificate store of the local machine using the open sign applet. This gives the opportunity to show only the certificates belonging to the owner of this particular machine/device. When wanting to use certificates stored on a key server on mobile devices, it is not always desirable or possible to transfer information about which certificates belongs to which users. Therefore, each session must start by the user identifying himself by entering his user name in a text input field. Even though it is common to allow the browser to store the password, it is now allowed to do so in this scenario, due to restrictions in the certificate policy. Signaturgruppen 4/ Page 4 of 10

5 3 Recommendations 3.1 Visual appearance Since the page, containing the LSS Client, in many cases will be put on a separate tab next to the other NemID options. The visual appearance should not differ too much from the design included in the other options. However, it is recommended that the design should distinguish itself from the other options in order to avoid confusion. This could cause the user to enter his or her credentials in the wrong place. 3.2 Sizing The LSS implementation must be able to fit inside the size of the LSS Client frame. The minimum size a service provider may use for the LSS Client is 200*270 pixels. For the login flow this is sufficient and the recommended size. For signing flows it is recommended that the service provider setup a 500*450 pixel frame if possible. 3.3 Internal error handling Some errors, such as No such user or Wrong passwords are handled internally by the LSS for NemID backend. Error messages should be displayed within the LSS Client without the need for scrolling. Signaturgruppen 4/ Page 5 of 10

6 3.4 Help messages Like with internal error messages, help texts should be displayed within the LSS Client without the need for scrolling. Should it be necessary to refer to a helpdesk function within the help messages, it should be possible to refer to the local help desk of the company or organization, owning the LSS implementation. Signaturgruppen 4/ Page 6 of 10

7 3.5 Certificate selection In some LSS implementations, it is possible for the users to have multiple certificates. This calls for a mechanism, allowing the user to select one of his multiple certificates for this specific operation. The LSS for NemID backend implementation should remember the certificate used last for operation, in order to avoid that the user has to select a certificate each time, under the assumption that he has a certificate that he uses more than the others. In case the user only has one certificate, the certificate selection mechanism should not be displayed. 3.6 Remembering user name The user should be able to have his or hers username remembered between sessions. As the LSS Client is running through an iframe the cookies set by the LSS back-end are by definition third party cookies. Currently, Firefox and Chrome supports third party cookies. IE has support if a P3P header is included in the response, but Safari is by default blocking all third party cookies. For that reason it is required that LSS suppliers implement their backend service without the use of cookies to accommodate all browsers. Signaturgruppen 4/ Page 7 of 10

8 As an alternative for cookies the LSS for NemID backend implementation could utilize the HTML5 Web Storage framework. 3.7 Presenting text to sign During the signing flow, the user must always be able to see the entire document, which he is about to sign. It should be as easy as possible for the user to browse or magnify the signing text, in order to make it as readable as possible. 3.8 Presenting text to sign in PDF format Not all browsers are able to render documents in PDF format natively. This is especially a problem on mobile devices. If the LSS backend implements PDF signature flows it is important that the PDF rendered for the user are the PDF signed and returned to the service provider. Signaturgruppen 4/ Page 8 of 10

9 3.9 Printing mechanism for signing document LSS for NemID backend implementations should implement a mechanism for printing the document, which the user is about to sign Download of pdf documents to be signed LSS for NemID backend implementations should implement a mechanism allowing users to download the PDF document presented to them for signature in the LSS Client. Signaturgruppen 4/ Page 9 of 10

10 4 Accessibility LSS for NemID backend implementations should comply with the W3C recommendations regarding accessibility known as WCAG. The points to be especially concerned about in the recommendation are the following - Readability: It is important that all elements are readable. In particular, the text to be signed must be readable to conform to the what you see is what you sign requirement. This means that the LSS suppliers must be careful when choosing colors and contrast of the UI. It is also important that all text must be zoom-able up to 200%. - Functionality: Everything should be controllable using keyboard only and the tab and focus order should be natural It is also recommended to test the solution with a reading tool for disabled. Signaturgruppen 4/ Page 10 of 10