for e-Government
|
Open Interfaces for e-Government |
|
User Interface Requirements
|
Designation |
User interface requirements for the Citizen Card Environment of the Austrian Citizen Card |
|
Short name |
User interface requirements |
|
Version |
1.2.1 |
|
Date |
2014-01-14 |
|
Document class |
Convention |
|
Document status |
Recommendation |
|
Short Name |
This document specifies the user interface requirements for the Citizen Card Environment according to the Citizen Card model. |
|
Authors |
Arno Hollosi |
|
Work group |
Federal Chancellery, Federal Staff Unit for ICT Strategy, Technology and Standards |
|
© |
This specification is supplied by A-SIT and the Federal Chancellery. It may be used without modification provided that reference is made to this copyright notice. The specification may be expanded, however any additional material must be clearly identified and the expanded specification must be made freely available. |
The Citizen Card Environment must communicate with the citizen via the user interface when executing most of the commands specified in Security Layer application interface. This document defines the minimum requirements for such communication.
This document uses the following keywords to categorise requirements: must, must not, required, should, should not, recommended, may, and optional. The interpretation of these keywords is set down in [Keywords].
For better readability, this document dispenses with non-gender-specific formulations. However, the formulations expressly relate to both sexes.
The following name space prefixes are used in this specification to identify the name spaces of XML elements:
|
Prefix
|
Name space
|
Explanation
|
sl |
http://www.buergerkarte.at/namespaces/securitylayer/1.2# |
Elements of this specification |
Initial communication with the citizen will generally take place via the user interface during verification of whether or not a command is to be executed by the Citizen Card Environment (cf. Access control, section 3.1). Depending on how the rules for executing a particular command are set, the rule verification results in one of four types of interaction. The following list defines how these types of interaction are to be implemented via the user interface.
none
info
confirm
info interaction type.
confirmWithSecret
confirm interaction type, the Citizen Card Environment must obtain the permission of the citizen before executing the command. Furthermore, in the event of a positive decision, the citizen must document this decision by transmitting a password to the Citizen Card Environment. The password must be transmitted to a server-based Citizen Card Environment in an encrypted connection. Also, the execution of commands must be logged as described for the info interaction type.
In addition to the user interactions explained above as part of access control, there is a series of commands from the Security Layer application interface that requires a special type of user interaction as part of command processing by the Citizen Card Environment. These issues are dealt with separately below according to the individual commands.
Before the signature is created, the Citizen Card Environment must allow the citizen to view the document(s) to be signed (depending on the signature format used).
If an external software is used for viewing the document, the Citizen Card Environment must explicitly state to the citizen, that an external software is used for viewing the document.
In addition to the document(s) to be signed, the Citizen Card Environment must also show the citizen the time at which the signature was created, as this time is included as a signature attribute and signed together with the actual documents (cf. Security Layer application interface, sections 2.1.2 and 2.2.2). Sensibly, the Citizen Card Environment will use the time when the signature creation command was called.
Before activating the signature function and the possibly associated entry of a signature PIN, the Citizen Card Environment must clearly inform the citizen of the key to be used to create the signature. A suitable way to do this is to display the certificate belonging to the key.
When the signature function is activated, the Citizen Card Environment must allow the citizen to save both the signature and signed documents locally.
After the signature has been verified, the Citizen Card Environment must show the citizen a clear summary of the verification results. The result of the cryptographic verification (hash values and signature value) must be displayed. If it was possible to perform the certificate check (i.e. if a signatory certificate issued for the key used was found), the result of this check (validity of the signatory certificate, trustworthiness of the signatory certificate) must be displayed. Furthermore, the Citizen Card Environment must then also show the citizen all the significant features of the signatory certificate. Significant features are the name of the signatory (Subject DN), the name of the issuing certification service provider (Issuer DN), the serial number of the certificate and the certificate extensions for identifying a qualified certificate or the administrative property.
If the signature to be verified contains an attribute that has also been signed which includes the signature creation time stated by the signatory (cf. Security Layer application interface, sections 2.1.2 and 2.2.2), the Citizen Card Environment must also show this time to the citizen and clearly identify it as the time stated by the signatory.
The Citizen Card Environment must allow the citizen to view the signed documents if it was possible to perform at least the cryptographic verification. If it is not possible to display the signed documents using the viewer component of the Citizen Card Environment, the Citizen Card Environment must allow the citizen to view the signed data using an external viewer. For example, the Citizen Card Environment could allow saving such a document, so that it can then be loaded using external software and displayed. It would also be conceivable for the Citizen Card Environment to call up external software directly in order to display a signed document. In the latter case, the Citizen Card Environment must make it clear to the citizen that external software is being used for viewing.
Finally, as part of signature verification, the Citizen Card Environment must allow the citizen to save both the signature and signed documents locally.
The Citizen Card Environment must allow the citizen to view all documents to be encrypted before sending the command response to the application. If the internal viewer component cannot be used to display them, the Citizen Card Environment must allow the citizen to view the documents to be encrypted with an external viewer. For example, the Citizen Card Environment could allow saving such a document, so that it can then be loaded using external software and displayed. It would also be conceivable for the Citizen Card Environment to call up external software in order to display a document to be encrypted.
Before the encryption function is activated, the Citizen Card Environment must clearly inform the citizen of the identity of the recipient of the encrypted data. A suitable way to do this is to display the certificate belonging to the encryption key used.
In the case of a local Citizen Card Environment it can happen that a citizen has several cryptographic tokens for keeping decryption keys. If this is the so, the Citizen Card Environment should provide the citizen with information about selecting a suitable decryption key, assuming that it has the relevant information (e.g. via the certificate for the encryption key specified in the encryption data).
If an encryption PIN has to be entered in order to activate the decryption function, the Citizen Card Environment must clearly inform the citizen of which key is used for decryption purposes. A suitable way to do this is to display the relevant certificate.
Before the Citizen Card Environment sends the command response, it must allow the citizen to view all decrypted documents. If the internal viewer component cannot be used for viewing, the Citizen Card Environment must allow the citizen to view the decrypted documents with an external viewer. For example, the Citizen Card Environment could allow saving such a document, so that it can then be loaded using external software and displayed. It would also be conceivable for the Citizen Card Environment to call up external software directly in order to display a decrypted document.
Furthermore, before the Citizen Card Environment sends the command response, it must allow the citizen to save all decrypted documents locally.
Before sending the command response, the Citizen Card Environment must show the citizen the result of the hash value calculation. For each hash value calculated, it must display at least the following features:
If the internal viewer component cannot be used for viewing, the Citizen Card Environment must allow the citizen to view the documents to be hashed with an external viewer. For example, the Citizen Card Environment could allow saving such a document, so that it can then be loaded using external software and displayed. It would also be conceivable for the Citizen Card Environment to call up external software in order to display a document to be hashed.
Furthermore, the Citizen Card Environment must provide the citizen with an easy way to call up, via the user interface, the features mentioned above for all hash value calculations executed during a Citizen Card Environment session. If hash value calculations are called up at a later point in this way, the Citizen Card Environment must also show the citizen the time (date and time) of the hash value calculation in addition to the features mentioned above.
Before sending the command response, the Citizen Card Environment must show the citizen the result of the hash value verification. For each hash value verified, it must display at least the following features:
If the internal viewer component cannot be used for viewing, the Citizen Card Environment must allow the citizen to view the documents to be hashed with an external viewer. For example, the Citizen Card Environment could allow saving such a document, so that it can then be loaded using external software and displayed. It would also be conceivable for the Citizen Card Environment to call up external software in order to display a document to be hashed.
Furthermore, the Citizen Card Environment must provide the citizen with an easy way to call up, via the user interface, the features mentioned above for all hash value verifications executed during a Citizen Card Environment session. If hash value calculations are called up at a later point in this way, the Citizen Card Environment must also show the citizen the time (date and time) of the hash value verification in addition to the features mentioned above.
Before it assembles the command response, the Citizen Card Environment must allow the citizen to select the info boxes to be included in the command response from the set of info boxes actually contained in the Citizen Card Environment. This enables the citizen to limit the visibility of his info boxes.
Before the Citizen Card Environment creates the info box and sends the command response to the application, it must show the citizen the parameters of the info box to be created from the command request and allow him to change individual parameters and to reject the creation of the info box.
Displaying the parameters from the command response must encompass the following elements:
sl:InfoboxIdentifer);
sl:InfoboxType);
sl:Creator);
sl:Purpose);
sl:ReadAccessAuthorization);
sl:UpdateAccessAuthorization);
sl:ReadUserConfirmation);
sl:UpdateUserConfirmation). It must not be possible for the citizen to change the name and type of the info box. It must be possible for the citizen to change the information about the creating application and the purpose of the info box.
If the UserMayChange attribute in the command request is set to true, the citizen must be able to change the corresponding proposal for an authorisation or confirmation. If, by contrast, the value of the UserMayChange attribute is set to false, the citizen must not change the proposal.
If the command request is missing individual proposals for authorisations and confirmations, the Citizen Card Environment must make appropriate proposals to the citizen, which the citizen must be able to change.
If the citizen fundamentally opposes the creation of the info box or disagrees with certain inalterable proposals for authorisations and confirmations, he must have the option of refusing to create the info box.
There is no command-specific user interaction specified for this command. The rules for interaction within the framework of access control are not affected by this.
If the UserMakesUnique attribute is set to true in the command request for reading keys or reading keys and values from an associative array type info box, and if the search item specified in the command request leads to more than one matching key, the Citizen Card Environment must allow the citizen
to select precisely one key from the set of matching keys. In the
command response, this particular key, or this particular key plus the
allocated value, must be sent to the application. If the command request explained above does not lead to a hit, or leads to exactly one hit, the user interaction described should not take place.
There is no command-specific user interaction specified for this command. The rules for interaction within the framework of access control are not affected by this.
There is no command-specific user interaction specified for this command. The rules for interaction within the framework of access control are not affected by this.
If the command request contains the two elements sl:TokenStatus and sl:MaxDelay and if the current status of the Citizen Card token does not match the one specified in the command request, the Citizen Card Environment must prompt the citizen via the user interface to establish the required status. If the citizen allows the time specified in MaxDelay to elapse without establishing the required status, the Citizen Card Environment must report the unchanged status back to the application in the command response.
There is no command-specific user interaction specified for this command. The rules for interaction within the framework of access protection are not affected by this.
| Date | Version | Changes |
|---|---|---|
| 2014-05-27 | 1.2.1 |
|
| 2004-05-14 | 1.2.0 |
|