Logo BKA Open Interfaces
for e-Government
Logo A-SIT

The Austrian Citizen Card

Tutorial


Document information

Designation Tutorial for the Austrian Citizen Card
Short name Tutorial
Version 1.2.2
Date 01-08-2006
Document class Explanation
Document status Public draft
Brief description This document contains a tutorial for application developers that explains how to use the Security Layer application interface.
Authors Arno Hollosi
Gregor Karlinger
Peter Teufl
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.

Table of contents

  1. General information
  2. Interface commands
    1. Creating signatures
      1. Creating a signature in CMS format
        1. Initial example
        2. Specifying data to be signed as a reference
      2. Creating a signature in XMLDSIG format
        1. Initial example
        2. Options for specifying the data to be signed
        3. Transformations
        4. Signature types (enveloping, enveloped, detached)
        5. Supplementary objects, signature manifest
    2. Verifying signatures
      1. Verifying a signature in CMS format
        1. Initial example
        2. Extended example
      2. Verifying a signature in XML format
        1. Initial example
        2. Extended example
        3. Checking XMLDSIG manifests
        4. Supplementary objects
    3. Data encryption
      1. Data encryption using the CMS standard
        1. CMS encryption using base64 encoded data
        2. CMS encryption using a reference
      2. Data encryption using the XMLENC standard
        1. Encryption of a complete XML document (New)
        2. Encryption of an element within an existing XML document (Element)
        3. Encryption of the content of an element which is located within an existing XML document (ElementContent)
    4. Data decryption
      1. Data decryption using the CMS standard
      2. Data decryption using the XMLENC standard
    5. Calculating the hash value
      1. Initial example
    6. Verifying the hash value
      1. Initial example
    7. Info boxes
      1. Reading out available info boxes
      2. Creating an info box
        1. Initial example
        2. Extended example
      3. Deleting an info box
      4. Reading an info box
        1. Reading a binary file
          1. Initial example
          2. Reading of the person identity link by the private sector
        2. Reading an associative array
          1. Reading keys
          2. Reading the value for a key
          3. Reading key/value pairs
      5. Changing an info box
        1. Changing a binary file
        2. Changing an associative array
          1. Adding/Changing a value
          2. Changing a key
          3. Deleting a key/value pair
    8. Requesting properties
      1. Environment properties
      2. Token status
    9. Null operation
    10. Error handling
  3. Transport protocols
    1. TCP/IP and TLS
    2. HTTP and HTTPS
      1. Result returned to the browser
        1. Result as XML
        2. Transformed result as HTML
      2. Result returned to the application server
        1. Asynchronous user guidance with RedirectURL and DataURL
        2. Synchronous user guidance with DataURL
        3. Using forwarding parameters and forwarding headers
        4. Command cascading via DataURL
      3. Typical application scenarios
        1. Transmitting a person identity link and signing a document (Sign On)
        2. Signing an application with annexes
  4. Standardised viewer format SLXHTML
    1. Initial example
    2. Comprehensive example
    3. Signing SLXHTML document images
      1. Initial example
      2. Image data as supplementary object

1 General information

This tutorial is intended for application developers in the e-Government and e-Commerce areas. It offers a practical overview of how the functions of the Citizen Card can be integrated in such applications.

Section 2 discusses sample interface commands for all Citizen Card functions.

Section 3 explains how to issue commands to the Citizen Card Environment using the specified transport protocols, TCP/IP or TLS and HTTP or HTTPS. In particular, the many options offered by the last pair of protocols for controlling the processing of commands between the citizen, Citizen Card Environment and application. Finally, this section also shows how Citizen Card function calls can be combined to form sequences as required for typical operations in applications.

Section 4 deals with the standardised viewer format for the Citizen Card. It discusses the basic structure of a corresponding XHTML document and provides a comprehensive example demonstrating the available document structuring and formatting options. Finally, this section also deals with signing documents in the standardised viewer format that contain images.

The document is currently incomplete and should be regarded as a work-in-progress. If you have any suggestions, please contact the authors by e-mail.

2 Interface commands

This section provides examples of all interface commands. You can test out all examples directly with the exception of example 2.7.4.1.2 by using the Sending Interface Commands form.

2.1 Creating a signature

2.1.1 Creating a signature in CMS format

2.1.1.1 Initial example

Request

First let's look at a simple example: The text Ich bin ein einfacher Text. is to be signed with a signature key that provides a secure signature or administrative signature. The corresponding request looks like this:

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:CreateCMSSignatureRequest
[03] xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#"
[04] Structure="enveloping">
[05] <sl:KeyboxIdentifier>SecureSignatureKeypair</sl:KeyboxIdentifier>
[06] <sl:DataObject>
[07] <sl:MetaInfo>
[08] <sl:MimeType>text/plain</sl:MimeType>
[09] </sl:MetaInfo>
[10] <sl:Content>
[11] <sl:Base64Content>SWNoIGJpbiBlaW4gZWluZmFjaGVyIFRleHQu</sl:Base64Content>
[12] </sl:Content>
[13] </sl:DataObject>
[14] </sl:CreateCMSSignatureRequest>

Line 2 contains the relevant command of the Security Layer interface.

Line 3 contains the name space declaration for the XML elements that comprise the request.

In line 4, the Structure attribute, whose value is set to enveloping, defines that the CMS signature to be created also contains the signed data. If the data itself is not to be encoded in the signature, this attribute must be set to detached.

The signature key to be used is selected by means of the content of the sl:KeyboxIdentifier in line 5. In line with the Standardised key and info boxes specification, the SecureSignatureKeypair value is to be specified when creating a secure signature or administrative signature.

Lines 6 to 13 contain the details of the data to be signed:

Lines 7 to 9 contain meta information about this data; only the mime type of the data is of interest in this example. Because a simple text is to be signed, the mime type must be specified in line 8 as the content of the sl:MimeType element with text/plain. It is important to specify the mime type, because it is analysed by the Citizen Card Environment in order to select the appropriate viewer component.

Lines 10 to 12 specify the actual data to be signed. The sl:Base64Content element contains the base64 encoding of the data to be signed, in other words of the text Ich bin ein einfacher Text.

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted and shortened for better readability, although this naturally breaks the electronic signature.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:CreateCMSSignatureResponse xmlns="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[03]   <sl:CMSSignature>MIIHGQYJKoZIhvcNAQcCoIIHCjCCBwYCAQExCzAJBgUrDgMCGgUAMCoGCSqGSIb3DQEHAaAdBBtJ
[04] Y2ggYmluIGVpbiBl...Y0245Zi7CH83+/97dnOUZH9Ug2B+WAJGjAS9o97ZFSx+gowRc3FEG
[05] IivzaAL5ARJzHV7wwIizxTPWVzSk/i5Zq8qHvlv3mbJ4QF84ArxhHKVSfG7GgWFHuQVApQyk</sl:CMSSignature>
[06] </sl:CreateCMSSignatureResponse>

Line 2 contains the response from the Citizen Card Environment to the request.

Lines 3 to 5 contain the CMS signature created by the Citizen Card Environment: This is stored as the text content of the sl:CMSSignature element in base64-encoded form (shown in abbreviated form above).

Downloads for this example
Further information

2.1.1.2 Specifying data to be signed as a reference

Request

Unlike the previous example, here an XHTML document is to be signed which corresponds to the standardised viewer format for the Citizen Card. The document to be signed is not to be included directly in the signature creation request, but is to be referenced by a URL. Here is the corresponding request:

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:CreateCMSSignatureRequest
[03] xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#"
[04] Structure="enveloping">
[05] <sl:KeyboxIdentifier>CertifiedKeypair</sl:KeyboxIdentifier>
[06] <sl:DataObject>
[07] <sl:MetaInfo>
[08] <sl:MimeType>application/xhtml+xml</sl:MimeType>
[09] </sl:MetaInfo>
[10] <sl:Content
[11] Reference="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/
[12] 20040514/tutorial/examples/viewerformat/Simple.xhtml"/>
[13] </sl:DataObject>
[14] </sl:CreateCMSSignatureRequest>

Line 5 defines that this time the second standardised signature key of the Citizen Card should be used for signing (value CertifiedKeypair).

The appropriate mime type for the XHTML document to be signed is specified in line 8. The value for XHTML documents is application/xhtml+xml.

In lines 10 to 12, the XHTML document to be signed is selected by specifying a reference. The Reference attribute must have a URL as content that can be resolved by the Citizen Card Environment. Please note that the value specified above includes a line break for better readability.

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted and shortened for better readability, although this naturally breaks the electronic signature.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:CreateCMSSignatureResponse xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[03]   <sl:CMSSignature>MIIH7wYJKoZIhvcNAQcCoIIH4DCCB9wCAQExCzAJBgUrDgMCGgUAMIIBMwYJKoZIhvcNAQcBoIIB
[04] JASCASA8P3htbCB2ZXJzaW9u...xLjAiIGVuY29kaW5nPSJVVEYtOCI/Pg0KPGh0bWwgeG1sbnM9
[05] mP+qV0lB2W21q2LL3eMldPKsJVgArkXEduw01jNybLeyU8SE+LTe6D1tR0B/PGFHbC6Yeu0bvD2c
[06] qq06QG+hKX+11S8bZHq3EB81MTcrSP4foYsf6aqxhBpYkHZcncEBoA==</sl:CMSSignature>
[07] </sl:CreateCMSSignatureResponse>

Line 2 contains the response from the Citizen Card Environment to the request.

Lines 3 to 5 contain the CMS signature created by the Citizen Card Environment. This is stored as the text content of the sl:CMSSignature element in base64-encoded form (shown in abbreviated form above).

Downloads for this example
Further information

2.1.2 Creating a signature in XMLDSIG format

2.1.2.1 Initial example

Request

In this example, the same data is to be signed as in section 2.1.1.1, in other words the text Ich bin ein einfacher Text. However, this time a signature is to be created in XMLDSIG format. The corresponding request looks like this:

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:CreateXMLSignatureRequest
[03] xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04] <sl:KeyboxIdentifier>SecureSignatureKeypair</sl:KeyboxIdentifier>
[05] <sl:DataObjectInfo Structure="enveloping">
[06] <sl:DataObject>
[07] <sl:XMLContent>Ich bin ein einfacher Text.</sl:XMLContent>
[08] </sl:DataObject>
[09] <sl:TransformsInfo>
[10] <sl:FinalDataMetaInfo>
[11] <sl:MimeType>text/plain</sl:MimeType>
[12] </sl:FinalDataMetaInfo>
[13] </sl:TransformsInfo>
[14] </sl:DataObjectInfo>
[15] </sl:CreateXMLSignatureRequest>

Line 2 contains the relevant command of the Security Layer interface.

The signature key to be used is selected by means of the content of the sl:KeyboxIdentifier in line 4. In line with the Standardised key and info boxes specification, the SecureSignatureKeypair value is to be specified when creating a secure signature or administrative signature.

Lines 5 to 14 contain the details of the data to be signed:

In line 5, the Structure attribute is used to define that the data to be signed shall be added to the XML signature to be created. The value of this attribute is to be set to enveloping for this purpose.

Lines 6 to 8 specify the reference input data. In this first example, the data is specified within the sl:XMLContent container, which can accommodate any number of XML nodes (elements, text, comments). In this specific case, only the text node is to be signed (Ich bin ein einfacher Text.) is specified.

Lines 9 to 13 contain information about how the reference input data in lines 6 to 8 is to be transformed to hash input data before actually being signed. In this specific case, the reference input data is to be signed directly, which is why sl:TransformsInfo does not contain the information about the transformations to be used. Only the mime type of the reference input data needs to be defined for the text to be signed with text/plain (in line 11).

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted and shortened for better readability, although this naturally breaks the electronic signature.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:CreateXMLSignatureResponse
[03] xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04] <dsig:Signature
[05] Id="signature-1084461392813"
[06] xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[07] <dsig:SignedInfo>
[08] <dsig:CanonicalizationMethod
[09] Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
[10] <dsig:SignatureMethod
[11] Algorithm="http://www.buergerkarte.at/namespaces/ecdsa/20020630#"/>
[12] <dsig:Reference
[13] Id="reference-0-1084461392813"
[14] URI="#xpointer(id('signed-data-0-1084461392813')/node())">
[15] <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[16] <dsig:DigestValue>7Dp/5KcvUfCnkohkOOzvFaeAIRc=</dsig:DigestValue>
[17] </dsig:Reference>
[18] <dsig:Reference
[19] Type="http://uri.etsi.org/01903/v1.1.1#SignedProperties"
[20] URI="#xpointer(id('etsi-signed-1084461392813')/*/*)">
[21] <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[22] <dsig:DigestValue>uUonRdJqrlWLyWfEVzz7uOXvFD8=</dsig:DigestValue>
[23] </dsig:Reference>
[24] </dsig:SignedInfo>
[25] <dsig:SignatureValue>
[26] OXxSRlOBBH84Psc3MRgVpEWZgzsAQa4bDz/01RrtoWWH8iJPImco9yn/kFMdfIvO
[27] </dsig:SignatureValue>
[28] <dsig:KeyInfo><!-- ... --></dsig:KeyInfo>
[29] <dsig:Object
[30] Id="signed-data-0-1084461392813">Ich bin ein einfacher Text.</dsig:Object>
[31] <dsig:Object Id="etsi-signed-1084461392813"><!-- ... --></dsig:Object>
[32] </dsig:Signature>
[33] </sl:CreateXMLSignatureResponse>

Line 2 contains the response from the Citizen Card Environment to the request.

Lines 4 to 32 contain the XML signature created by the Citizen Card Environment:

Lines 12 to 17 show the dsig:Reference created for the data to be signed as specified in the request. It is apparent that no transformations have been added to the dsig:Reference.

Lines 25 to 27 contain the actual signature value calculated.

Line 30 shows a dsig:Object container which the Citizen Card Environment has created in order to encode the data to be signed as specified in the request. Reference is then made to this data by means of the URI attribute from the dsig:Reference.

Downloads for this example
Further information

2.1.2.2 Options for specifying the data to be signed

The interface command for creating a signature provides for a total of three different ways in which the data to be signed can be specified:

Request

The following request contains examples of how all three options are used:

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:CreateXMLSignatureRequest xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[03] <sl:KeyboxIdentifier>SecureSignatureKeypair</sl:KeyboxIdentifier>
[04] <sl:DataObjectInfo Structure="detached">
[05] <sl:DataObject Reference="http://www.example.com/Simple.txt">
[06] <sl:Base64Content>SWNoIGJpbiBlaW4gZWluZmFjaGVyIFRleHQu</sl:Base64Content>
[07] </sl:DataObject>
[08] <sl:TransformsInfo>
[09] <sl:FinalDataMetaInfo>
[10] <sl:MimeType>text/plain</sl:MimeType>
[11] </sl:FinalDataMetaInfo>
[12] </sl:TransformsInfo>
[13] </sl:DataObjectInfo>
[14] <sl:DataObjectInfo Structure="enveloping">
[15] <sl:DataObject>
[16] <sl:XMLContent>
[17] <html xmlns="http://www.w3.org/1999/xhtml">
[18] <head>
[19] <title>Ein einfaches SLXHTML-Dokument</title>
[20] <style type="text/css">p { color: red; }</style>
[21] </head>
[22] <body>
[23] <p>Ich bin ein einfacher Text in rot.</p>
[24] </body>
[25] </html>
[26] </sl:XMLContent>
[27] </sl:DataObject>
[28] <sl:TransformsInfo>
[29] <sl:FinalDataMetaInfo>
[30] <sl:MimeType>application/xhtml+xml</sl:MimeType>
[31] </sl:FinalDataMetaInfo>
[32] </sl:TransformsInfo>
[33] </sl:DataObjectInfo>
[34] <sl:DataObjectInfo Structure="detached">
[35] <sl:DataObject Reference="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/
[36] 20040514/tutorial/examples/viewerformat/Simple.xhtml"/>
[37] <sl:TransformsInfo>
[38] <sl:FinalDataMetaInfo>
[39] <sl:MimeType>application/xhtml+xml</sl:MimeType>
[40] </sl:FinalDataMetaInfo>
[41] </sl:TransformsInfo>
[42] </sl:DataObjectInfo>
[43] <sl:DataObjectInfo Structure="detached">
[44] <sl:DataObject Reference="http://www.example.com/Simple.xhtml">
[45] <sl:LocRefContent>http://www.buergerkarte.at/konzept/securitylayer/spezifikation/
[46] 20040514/tutorial/examples/viewerformat/Simple.xhtml</sl:LocRefContent>
[47] </sl:DataObject>
[48] <sl:TransformsInfo>
[49] <sl:FinalDataMetaInfo>
[50] <sl:MimeType>application/xhtml+xml</sl:MimeType>
[51] </sl:FinalDataMetaInfo>
[52] </sl:TransformsInfo>
[53] </sl:DataObjectInfo>
[54] </sl:CreateXMLSignatureRequest>

In lines 4 to 13, data is specified for the creation of a so-called Detached Signature (in simple terms, Detached Signature in this case means that the signed data is not encoded in the same document as the XML signature – for more information see example 2.1.2.4). For a Detached Signature, the Structure attribute in line 4 must be set to detached. Furthermore, the sl:DataObject/@Reference attribute is to be specified in line 5; its value contains a URI in the form in which it is to be included in the dsig:Reference/@URI of the signature to be created. In this example, the URL has been purposely chosen so that it cannot be resolved by the Citizen Card Environment. The data must also be specified explicitly so as to prevent this situation leading to an error: The sl:Base64Content element in line 6 of this example is used for this purpose; it contains the data to be signed in base64-encoded form. The Citizen Card Environment now behaves in such a way that it does not resolve the URL specified in sl:DataObject/@Reference but instead uses the data explicitly specified in sl:Base64Content. The signature created looks as if the Citizen Card Environment did indeed resolve the URL. This procedure is useful in cases in which a URL is not available when the signature is created, but is available during future checks, for example. Lines 8 to 12 contain metadata for the data to be signed, compare example 2.1.2.1).

Lines 14 to 33 contain the details of other data to be signed: As in example 2.1.2.1, an Enveloping Signature (compare the value of the Structure attribute in line 14) is to be created, which means that the data to be signed is encoded as part of the XML structure of the signature. The data to be signed, a simple XHTML document, is explicitly specified as XML data in lines 16 to 26 as content of the sl:XMLContent element. The sl:DataObject/@Reference attribute must not be specified here, because the data is included in the XML structure of the signature and is not referenced by a URL as above. Lines 28 to 32 contain metadata for the data to be signed, compare example 2.1.2.1).

The third data to be signed is specified in lines 34 to 42. As for the first data, a Detached Signature is to be created (compare the value of the Structure attribute in line 34). Unlike the first data, the data here is referenced directly by means of a resolvable URL (specified in the sl:DataObject/@Reference attribute in lines 34 and 35). The Citizen Card Environment can retrieve the data to be signed from there; for this reason, the data is not explicitly specified in the request. Lines 37 to 41 contain metadata for the data to be signed, compare example 2.1.2.1).

Finally, further data is to be signed as Detached Signature in lines 43 to 53. The Structure attribute in line 43 is therefore reset to detached. The sl:DataObject/@Reference attribute is to be specified in line 44; its value contains a URI as it must be included in the dsig:Reference/@URI of the signature to be created. As with the second data, a URL was selected that cannot be resolved by the Citizen Card Environment. For this reason, a source from which the Citizen Card Environment can retrieve the data must also be specified in the request. In contrast to the second data, no explicit encoding is selected in the request; instead, a URL that can be resolved by the Citizen Card Environment is specified with the sl:LocRefContent element (lines 44 and 45). The application scenarios for this variant are the same as for the first data. Lines 48 to 52 contain metadata for the data to be signed, compare example 2.1.2.1.

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted and shortened for better readability, although this naturally breaks the electronic signature.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:CreateXMLSignatureResponse xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[03] <dsig:Signature Id="signature-1084532870164" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[04] <dsig:SignedInfo>
[05] <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
[06] <dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
[07] <dsig:Reference Id="reference-0-1084532870164" URI="http://www.example.com/Simple.txt">
[08] <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[09] <dsig:DigestValue>7Dp/5KcvUfCnkohkOOzvFaeAIRc=</dsig:DigestValue>
[10] </dsig:Reference>
[11] <dsig:Reference Id="reference-1-1084532870164"
[12] URI="#xpointer(id('signed-data-1-1084532870164')/node())">
[13] <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[14] <dsig:DigestValue>W9Gsw+M74YGV2iUhMG0cvLQk0NA=</dsig:DigestValue>
[15] </dsig:Reference>
[16] <dsig:Reference Id="reference-2-1084532870164"
[17] URI="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/tutorial/
[18] examples/viewerformat/Simple.xhtml">
[19] <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[20] <dsig:DigestValue>DW8CLYLic6czUS32ZCDyyc1akdY=</dsig:DigestValue>
[21] </dsig:Reference>
[22] <dsig:Reference Id="reference-3-1084532870164" URI="http://www.example.com/Simple.xhtml">
[23] <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[24] <dsig:DigestValue>DW8CLYLic6czUS32ZCDyyc1akdY=</dsig:DigestValue>
[25] </dsig:Reference>
[26] <dsig:Reference Type="http://uri.etsi.org/01903/v1.1.1#SignedProperties"
[27] URI="#xpointer(id('etsi-signed-1084532870164')/*/*)">
[28] <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[29] <dsig:DigestValue>fcz4azQhn5Zo7E7h/h/8W/oRDe0=</dsig:DigestValue>
[30] </dsig:Reference>
[31] </dsig:SignedInfo>
[32] <dsig:SignatureValue><!-- ... --></dsig:SignatureValue>
[33] <dsig:KeyInfo><!-- ... --></dsig:KeyInfo>
[34] <dsig:Object Id="signed-data-1-1084532870164">
[35] <html xmlns="http://www.w3.org/1999/xhtml">
[36] <head>
[37] <title>Ein einfaches SLXHTML-Dokument</title>
[38] <style type="text/css">p { color: red; }</style>
[39] </head>
[40] <body>
[41] <p>Ich bin ein einfacher Text in rot.</p>
[42] </body>
[43] </html>
[44] </dsig:Object>
[45] <dsig:Object Id="etsi-signed-1084532870164"><!-- ... --></dsig:Object>
[46] </dsig:Signature>
[47] </sl:CreateXMLSignatureResponse>

Line 1 contains the response from the Citizen Card Environment to the request.

Lines 2 to 47 contain the XML signature created by the Citizen Card Environment:

Lines 7 to 10 show the dsig:Reference created by the Citizen Card Environment for the first data to be signed. It is apparent that this is a Detached Signature, because the URI attribute contains a reference from the signature document. This is the unresolvable URL http://www.example.com/Simple.txt specified in the request.

Lines 11 to 15 show the dsig:Reference created by the Citizen Card Environment for the second data to be signed. As defined in the request, an Enveloping Signature has been created: The URI attribute contains an internal reference (#xpointer(id('signed-data-1-1084532870164')/node())) that refers to the data integrated accordingly in the XML structure of the signature (cf. lines 35 to 43).

Lines 16 to 21 represent the dsig:Reference corresponding to the third data to be signed. In accordance with the request, a Detached Signature was created here for the data retrieved by the Citizen Card Environment from the URL specified in the request. It is apparent in lines 17 and 18 that the specified URL has also been copied to the URI attribute of the dsig:Reference.

Lines 22 to 25 represent the dsig:Reference corresponding to the fourth data to be signed. The data was resolved by the Citizen Card Environment from the URL specified in the sl:LocRefContent element of the request, however, the value from the sl:DataObject/@Reference attribute of the request (cf. line 44 of the request) was applied as a value of the URI attribute of dsig:Reference in line 22.

Downloads for this example
Further information

2.1.2.3 Options for specifying the data to be signed

Request

This example shows the most important transformations that can be used when creating an XML signature. A transformation or a chain of several consecutive transformations is applied to the reference input data (in other words the data specified in sl:DataObjectInfo/sl:DataObject); the hash value is then calculated for the result of the last transformation.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:CreateXMLSignatureRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#" 
[04]   xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[05]   <sl:KeyboxIdentifier>SecureSignatureKeypair</sl:KeyboxIdentifier>

Line 5 contains the information that a secure signature or administrative signature is to be created (SecureSignatureKeypair).

[06]   <sl:DataObjectInfo Structure="detached">
[07]     <sl:DataObject 
[08]       Reference="http://www.buergerkarte.at/konzept/securitylayer/\
[09]         spezifikation/20040514/tutorial/examples/interface/common/SimpleText.txt.b64"
[10]     <sl:TransformsInfo>
[11]       <dsig:Transforms>
[12]         <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"
[13]       </dsig:Transforms>
[14]       <sl:FinalDataMetaInfo>
[15]         <sl:MimeType>text/plain</sl:MimeType>
[16]       </sl:FinalDataMetaInfo>
[17]     </sl:TransformsInfo>
[18]   </sl:DataObjectInfo>

For the first data object to be signed, the reference data is referenced with DataObject/@Reference (lines 7 to 9), i.e. the Citizen Card Environment resolves the URL contained there in order to retrieve the data. The text in question is a base64-encoded text.

However, the text to be signed is the text decoded from base64, rather than the base64-encoded text itself. This can be achieved in an elegant way by specifying a base64 decoding transformation. For this, a dsig:Transforms element is specified as the first child element of CreateTransformsInfo (lines 11 to13). This dsig:Transforms element accommodates one or more dsig:Transform elements; each dsig:Transform element stands for a transformation. In our case, just one transformation is required; the actual transformation in question is specified by means of the dsig:Transform/@Algorithm attribute. For the base64 decoding transformation, the value must be set to http://www.w3.org/2000/09/xmldsig#base64. This transformation has no parameters, i.e. dsig:Transform has no child elements.

The mime type of the data to be signed is specified as text/plain, because decoded text exists after the transformation is complete and is used to calculate the hash value.

[19]   <sl:DataObjectInfo Structure="detached">
[20]     <sl:DataObject
[21]       Reference="http://www.buergerkarte.at/konzept/securitylayer/\
[22]         spezifikation/20040514/tutorial/examples/interface/common/XMLDocument.xml"
[23]     <sl:TransformsInfo>
[24]       <dsig:Transforms>
[25]         <dsig:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
[26]           <xp2:XPath xmlns:xp2="http://www.w3.org/2002/06/xmldsig-filter2" 
[27]             xmlns:doc="urn:document" Filter="subtract">/doc:XMLDocument/doc:Paragraph[2]
[28]           </xp2:XPath>
[29]         </dsig:Transform>
[30]         <dsig:Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">
[31] <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
[32] xmlns:doc="urn:document">
[33] <xsl:output encoding="UTF-8" method="xml" indent="yes"
[34] <xsl:template match="/doc:XMLDocument">
[35]   <html xmlns="http://www.w3.org/1999/xhtml">
[36]     <head>
[37]       <title>HTML-Dokument</title>
[38]     </head>
[39]     <body>
[40]       <xsl:for-each select="doc:Paragraph">
[41]         <p>
[42]           <xsl:value-of select="child::text()"/>
[43]         </p>
[44]       </xsl:for-each>
[45]     </body>
[46]   </html>
[47] </xsl:template>
[48] </xsl:stylesheet></dsig:Transform>
[49]         <dsig:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
[50]       </dsig:Transforms>
[51]       <sl:FinalDataMetaInfo>
[52]         <sl:MimeType>application/xhtml+xml</sl:MimeType>
[53]       </sl:FinalDataMetaInfo>
[54]     </sl:TransformsInfo>
[55]   </sl:DataObjectInfo>
[56] </sl:CreateXMLSignatureRequest> 

For the second data object to be signed, the reference data is referenced with DataObject/@Reference (lines 20 to 22), i.e. the Citizen Card Environment resolves the URL contained there in order to retrieve the data. The document in question is an XML document.

The first step is to cut away part of this XML document because it is not to be signed. The XPath Filter 2 Transformation can be used for this purpose (lines 25 to 29). For this, the dsig:Transform/@Algorithm attribute is to be set to the value http://www.w3.org/2002/06/xmldsig-filter2. This transformation also requires transformation parameters. These are specified as child element xp2:XPath in dsig:Transform. The Filter attribute selects the filter mode; the example requires subtract mode because part is to be filtered away. The text content of xp2:XPath is an XPath expression that selects the root node of the subtree to be filtered away. In the example, the second doc:Paragraph element of the XML document is to be filtered away. Please note that the doc namespace prefix used in the XPath expression must be declared in the context of the xp2:XPath element.

The next task is to transform the XML document into an XHTML document using a style sheet. The XSLT transformation can be used for this purpose (lines 30 to 48). For this, the dsig:Transform/@Algorithm attribute is to be set to the value http://www.w3.org/1999/REC-xslt-19991116. This transformation also requires transformation parameters. The style sheet to be used in order to execute the style sheet transformation is specified as the child element of dsig:Transform.

Finally, as recommended in the specification for the XSLT transformation, a canonicalisation transformation is to be applied. Thereby, differences in the output of different XSLT engines as they occur in practice can be harmonised. Please note the requirement that the output method in the style sheet must be set to xml (<xsl:output method="xml">), as only XML output can be canonised. The dsig:Transform/@Algorithm attribute is to be set to the value http://www.w3.org/2001/REC-xml-c14n-20010315 for the Canonical XML Transformation. This transformation does not require transformation parameters.

The result of the three consecutive transformations that goes into the hash value calculation can be found in the downloads for this example.

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted and shortened for better readability, although this naturally breaks the electronic signature.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:CreateXMLSignatureResponse 
[03]   xmlns:sl11="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <dsig:Signature Id="signature-0912200410273681" 
[05]     xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[06]     <dsig:SignedInfo>
[07]       <dsig:CanonicalizationMethod 
[08]         Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/>
[09]       <dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

The response contains the result of the signature creation in sl:CreateXMLSignatureResponse. Since the signature should not be inserted in an existing document, the element contains the created XML signature (dsig:Signature) directly.

[10]       <dsig:Reference Id="reference-0-0912200410273681" 
[11]         URI="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/\
[12]         tutorial/examples/interface/common/SimpleText.txt.b64">
[13]         <dsig:Transforms>
[14]           <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/>
[15]         </dsig:Transforms>
[16]         <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[17]         <dsig:DigestValue>7Dp/5KcvUfCnkohkOOzvFaeAIRc=</dsig:DigestValue>
[18]       </dsig:Reference>

The first dsig:Reference (lines 10 to 18) was created on the basis of the first DataObjectInfo in the request. It is apparent that the URL for the reference input data (value of the dsig:Reference/@URI attribute) was copied from DataObject/@Reference and a base64 decoding transformation was inserted. Thus, the transformations specified in the request are copied to the XML signature in identical form.

[19]       <dsig:Reference Id="reference-1-0912200410273681" 
[20]         URI="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/\
[21]         tutorial/examples/interface/common/XMLDocument.xml">
[22]         <dsig:Transforms>
[23]           <dsig:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
[24]             <xpf:XPath Filter="subtract" xmlns:doc="urn:document" 
[25]               xmlns:xpf="http://www.w3.org/2002/06/xmldsig-filter2">
[26]               /doc:XMLDocument/doc:Paragraph[2]
[27]             </xpf:XPath>
[28]           </dsig:Transform>
[29]           <dsig:Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">
[30]             <xsl:stylesheet version="1.0" 
[31]               xmlns:doc="urn:document" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
[32]               <xsl:output encoding="UTF-8" indent="yes" method="xml"/>
[33]               <xsl:template match="/doc:XMLDocument"><!--...--></xsl:template>
[34]             </xsl:stylesheet>
[35]           </dsig:Transform>
[36]           <dsig:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
[37]         </dsig:Transforms>
[38]         <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[39]         <dsig:DigestValue>fIPwneCpjVqTXwHMN9DFfx6tJIU=</dsig:DigestValue>
[40]       </dsig:Reference>

The second dsig:Reference (lines 19 to 40) was created on the basis of the second DataObjectInfo in the request. It is also apparent here that the URL for the reference input data (value of the dsig:Reference/@URI attribute) was copied from DataObject/@Reference and the three transformations were inserted as specified in the request.

[41]       <dsig:Reference Id="etsi-its-0-0912200410273681" 
[42]         Type="http://uri.etsi.org/01903/v1.1.1#SignedProperties" URI="">
[43]         <!--...-->
[44]       </dsig:Reference>
[45]     </dsig:SignedInfo>
[46]     <dsig:SignatureValue><!--...--></dsig:SignatureValue>
[47]     <dsig:KeyInfo><!--...--></dsig:KeyInfo>
[48]     <dsig:Object Id="etsi-signed-2-0912200410273681" 
[49]       xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[50]       <!--...-->
[51]     </dsig:Object>
[52]   </dsig:Signature>
[53] </sl:CreateXMLSignatureResponse>

A further reference to the signature properties follows (lines 41 to 44), as well as the signature value (line 46), key information (line 47) and signature properties (lines 48 to 52).

Downloads for this example
Further information

2.1.2.4 Signature types (enveloping, enveloped, detached)

Depending on where the XML signature structure (dsig:Signature) is located in relation to the signed data, the standard for XML signatures refers to an Enveloping, Enveloped or Detached Signature:

When this definition is considered more closely, it becomes apparent that it does not go far enough. Since an XML signature can sign several data units at once, it is quite possible for the same signature to be allocated to several of the classes defined above. The following example creates an XML signature that signs a total of four data units; for the first data unit, it corresponds to an Enveloping Signature, for the second, it corresponds to an Enveloped Signature, and for the third and fourth to a Detached Signature.

Request
[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:CreateXMLSignatureRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#" 
[04]   xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[05]   <sl:KeyboxIdentifier>CertifiedKeypair</sl:KeyboxIdentifier>

Line 5 contains the specification that a signature is to be created with the combined signature and encryption key (CertifiedKeypair).

[06]   <sl:DataObjectInfo Structure="enveloping">
[07]     <sl:DataObject>
[08]       <sl:XMLContent>Von der Signatur umschlossene Daten.</sl:XMLContent>
[09]     </sl:DataObject>
[10]     <sl:TransformsInfo>
[11]       <sl:FinalDataMetaInfo>
[12]         <sl:MimeType>text/plain</sl:MimeType>
[13]       </sl:FinalDataMetaInfo>
[14]     </sl:TransformsInfo>
[15]   </sl:DataObjectInfo>

For the first data unit (lines 6 to 15), the resulting XML signature corresponds to an Enveloping Signature, i.e. the data to be signed is enveloped by the XML signature. To put it more precisely, it will be embedded in a dsig:Object as a child of dsig:Signature.

For this, the Structure attribute is to be assigned the value enveloping in line 6. The data to be embedded in the dsig:Object, in this case a simple string, is specified in line 8 as the content of sl:XMLContent.

[16]   <sl:DataObjectInfo Structure="detached">
[17]     <sl:DataObject Reference=""/>
[18]     <sl:TransformsInfo>
[19]       <dsig:Transforms>
[20]         <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
[21]       </dsig:Transforms>
[22]       <sl:FinalDataMetaInfo>
[23]         <sl:MimeType>application/xml</sl:MimeType>
[24]       </sl:FinalDataMetaInfo>
[25]     </sl:TransformsInfo>
[26]   </sl:DataObjectInfo>

For the second data unit (lines 16 to 26), the resulting XML signature corresponds to an Enveloping Signature, i.e. the XML signature is enveloped by the data to be signed. This may sound contradictory at first because the XML signature would attempt to sign itself, which is impossible. How this can work nevertheless will be explained a little later on.

In order to create an Enveloping Signature, the Structure attribute in line 16 must be set to detached (Note: This is not a printing error but has historical reasons; when an Enveloping Signature is to be created, the detached value must still be used).

The whole XML document in which the signature to be created is to be inserted is supposed to be signed (cf. lines 52 to 56 further below). For this, the value of the Reference attribute in line 17 is to be assigned the empty string.

To prevent the signature from signing itself, it must be extracted from the data to be signed with the help of a transformation. This is the purpose of the specially invented Enveloping Signature transformation (cf. line 20); this transformation filters precisely the dsig:Signature element from the transformation input data. (Note: Of course, it would also be possible to define a suitable XPath Filter 2 transformation oneself for this purpose, the predefined Enveloping Signature transformation just simplifies the process.)

As the resulting data forms an XML structure, the mime type is set accordingly to application/xml in line 23.

[27]   <sl:DataObjectInfo Structure="detached">
[28]     <sl:DataObject Reference="http://www.buergerkarte.at/konzept/securitylayer/\
[29]       spezifikation/20040514/tutorial/examples/interface/common/SimpleText.txt"/>
[30]     <sl:TransformsInfo>
[31]       <sl:FinalDataMetaInfo>
[32]         <sl:MimeType>text/plain</sl:MimeType>
[33]       </sl:FinalDataMetaInfo>
[34]     </sl:TransformsInfo>
[35]   </sl:DataObjectInfo>

For the third data unit (lines 27 to 35), the resulting XML signature corresponds to a Detached Signature, i.e. the XML signature and the signed data are not particularly related with respect to their location (in other words they are separate and independent of each other).

First the value of the Structure attribute in line 27 is to be set to detached (Note: This time this makes sense ;-)).

An external text document is supposed to be signed which is referenced using the Reference attribute in line 28. The Citizen Card Environment will resolve this reference in order to retrieve the data to be signed; on the other hand, the value of the attribute will also be used in the dsig:Reference/@URI attribute of the XML signature.

The mime type in line 32 is once again set accordingly to text/plain.

[36]   <sl:DataObjectInfo Structure="detached">
[37]     <sl:DataObject Reference=""/>
[38]     <sl:TransformsInfo>
[39]       <dsig:Transforms>
[40]         <dsig:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
[41]           <xp2:XPath xmlns:xp2="http://www.w3.org/2002/06/xmldsig-filter2" 
[42]           xmlns:doc="urn:document" Filter="intersect">/doc:Whole/doc:Part2</xp2:Xpath>
[43]         </dsig:Transform>
[44]       </dsig:Transforms>
[45]       <sl:FinalDataMetaInfo>
[46]         <sl:MimeType>application/xml</sl:MimeType>
[47]       </sl:FinalDataMetaInfo>
[48]     </sl:TransformsInfo>
[49]   </sl:DataObjectInfo>

For the fourth data unit (lines 36 to 49), the resulting XML signature also corresponds to a Detached Signature, i.e. the XML signature and the signed data are once again not particularly related with respect to their location. Although this applies to a lesser extent than for the third data unit, the important thing is that neither the signature contains the data, nor does the data contain the signature. In this case, only a part of the XML document in which the signature to be created is to be integrated is signed (cf. lines 52 to 56 further below), and this part does not contain the XML signature.

Specifically, the Structure attribute is to be assigned the value detached in line 36. Similarly to the second data unit, the whole document in which the signature is to be inserted is selected in line 37. A large part of the document is discarded in lines 40 to 43 using an XPath Filter 2 transformation; all that is left is the document subtree, which is held open by the /doc:Whole/doc:Part2 element.

The remaining subtree is an XML structure, which is why the mime type is set to application/xml.

[50]   <sl:SignatureInfo>
[51]     <sl:SignatureEnvironment>
[52]       <sl:XMLContent>
[53]         <doc:Whole xmlns:doc="urn:document">
[54]           <doc:Part1>Text in Teil 1</doc:Part1>
[55]           <doc:Part2>Text in Teil 2</doc:Part2>
[56]         </doc:Whole>
[57]       </sl:XMLContent>
[58]     </sl:SignatureEnvironment>
[59]     <sl:SignatureLocation 
[60]       xmlns:doc="urn:document" Index="4">/doc:Whole</sl:SignatureLocation>
[61]   </sl:SignatureInfo>
[62] </sl:CreateXMLSignatureRequest>

The sl:SignatureInfo element in lines 52 to 61 must be specified if, as is the case here, the XML signature is to be embedded in an already existing XML document.

sl:SignatureEnvironment (lines 51 to 58) contains precisely this existing XML document. Basically, the same methods are available for this as for specifying data objects (cf. example 2.1.2.2). In this case, the document is specified directly in sl:XMLContent as an XML structure (lines 54 and 55).

The sl:SignatureLocation element specifies the position at which the XML signature is to be inserted in the existing XML document (lines 59 to 61). The text content of this element consists of an XPath expression that – when applied to the root node of the XML document – selects the element for which the dsig:Signature element is to be added as a child. (Note: The doc name space prefix used in the XPath expression must be known in the context of the sl:SignatureLocation element; this is why line 60 also contains the relevant name space declaration.) The Index attribute specifies the offset for dsig:Signature within this element; counting starts at 0. (Note: The value 4 for this example may seem wrong at first sight because the signature is to be inserted immediately after doc:Part2, however, the white space text nodes preceding doc:Part1 and doc:Part2 created by the indentation must also be taken into consideration.)

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted and shortened for better readability, although this naturally breaks the electronic signature.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:CreateXMLSignatureResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <doc:Whole xmlns:doc="urn:document">
[05]     <doc:Part1>Text in Teil 1</doc:Part1>
[06]     <doc:Part2>Text in Teil 2</doc:Part2>
[07]     <dsig:Signature Id="signature-09122004155437545" 
[08]       xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[09]       <dsig:SignedInfo>
[10]         <dsig:CanonicalizationMethod 
[11]           Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/>
[12]         <dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

It is evident that the response element sl:CreateXMLSignatureResponse does not directly contain a dsig:Signature element this time, but rather contains the XML document specified in the request (line 5 et seq.); the XML signature is inserted at the point specified in the request (immediately following doc:Part2, cf. lines 6 and 7).

[13]         <dsig:Reference Id="reference-0-09122004155437545" 
[14]           URI="#signed-data-0-09122004155437545">
[15]           <dsig:Transforms>
[16]             <dsig:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
[17]               <xpf:XPath Filter="intersect" 
[18]                 xmlns:xpf="http://www.w3.org/2002/06/xmldsig-filter2">
[19]                 //*[@Id='signed-data-0-09122004155437545']/node()</xpf:XPath>
[20]             </dsig:Transform>
[21]           </dsig:Transforms>
[22]           <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[23]           <dsig:DigestValue>G+UQZGU9uY8B7rW0yGvCLpo55ek=</dsig:DigestValue>
[24]         </dsig:Reference>

The first dsig:Reference (lines 13 to 24) corresponds to the first data unit from the request (ibid. lines 6 to 15). The URI attribute in line 14 uses an ID reference to refer to the dsig:Object in which the text specified in the request was embedded. In addition, the Citizen Card Environment independently inserted an XPath Filter 2 transformation (lines 16 to 20), so that not the whole dsig:Object is signed (see lines 62 and 63 below) but only the text contained there (see line 62 below).

[25]         <dsig:Reference Id="reference-1-09122004155437545" URI="">
[26]           <dsig:Transforms>
[27]             <dsig:Transform 
[28]               Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
[29]           </dsig:Transforms>
[30]           <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[31]           <dsig:DigestValue>dZoplbJsn4ooI/7oC8733wwFvTY=</dsig:DigestValue>
[32]         </dsig:Reference>

The second dsig:Reference (lines 25 to 32) corresponds to the second data unit from the request (ibid. lines 16 to 26).

[33]         <dsig:Reference Id="reference-2-09122004155437545" 
[34]           URI="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/\
[35]           20040514/tutorial/examples/interface/common/SimpleText.txt">
[36]           <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[37]           <dsig:DigestValue>7Dp/5KcvUfCnkohkOOzvFaeAIRc=</dsig:DigestValue>
[38]         </dsig:Reference>

The third dsig:Reference (lines 33 to 38) corresponds to the third data unit from the request (ibid. lines 27 to 35). It is apparent that the value of sl:DataObject/@Reference (request, lines 28 and 29) was applied directly to dsig:Reference/@URI (lines 34 and 35).

[39]         <dsig:Reference Id="reference-3-09122004155437545" URI="">
[40]           <dsig:Transforms>
[41]             <dsig:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
[42]               <xpf:XPath Filter="intersect" xmlns:doc="urn:document" 
[43]                 xmlns:xpf="http://www.w3.org/2002/06/xmldsig-filter2">
[44]                 /doc:Whole/doc:Part2</xpf:XPath>
[45]             </dsig:Transform>
[46]           </dsig:Transforms>
[47]           <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[48]           <dsig:DigestValue>7xBtEW4LIBb/UCX/YhZKZ/kMGPo=</dsig:DigestValue>
[49]         </dsig:Reference>

The fourth dsig:Reference (lines 39 to 49) corresponds to the fourth data unit from the request (ibid. lines 36 to 49).

[50]         <dsig:Reference Id="etsi-its-0-09122004155437545" 
[51]           Type="http://uri.etsi.org/01903/v1.1.1#SignedProperties" URI="">
[52]           <!--...-->
[53]       <dsig:SignatureValue><!--...--></dsig:SignatureValue>
[54]       <dsig:KeyInfo><!--...--></dsig:KeyInfo>
[55]       <dsig:Object Id="etsi-signed-2-09122004155437545" 
[56]         xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[57]         <etsi:QualifyingProperties Target="#signature-09122004155437545" 
[58]           xmlns:etsi="http://uri.etsi.org/01903/v1.1.1#">
[59]           <!--...-->
[60]         </etsi:QualifyingProperties>
[61]       </dsig:Object>
[62]       <dsig:Object Id="signed-data-0-09122004155437545">
[63]         Von der Signatur umschlossene Daten.</dsig:Object>
[64]     </dsig:Signature>
[65]   </doc:Whole>
[66] </sl:CreateXMLSignatureResponse>

Lines 62 to 64 contain the dsig:Object element in which the data to be signed from the first data unit of the request (ibid. line 8) was embedded.

Downloads for this example
Further information

2.1.2.5 Supplementary objects, signature manifest

This example shows how supplementary objects are used. A supplementary object either relates to a data item to be signed (see sl:DataObject) or to the document in which a signature to be created is to be inserted (parent document) (see sl:SignatureEnvironment). A supplementary object needs to be specified if data is to be referenced in a data item to be signed or in the parent document, but this referenced data cannot be resolved by the Citizen Card Environment. The supplementary object contains precisely this data that cannot be resolved by the Citizen Card Environment.

Furthermore, this example explains in which cases the Citizen Card Environment automatically integrates a so-called signature manifest in the XML signature to be created.

Request
[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:CreateXMLSignatureRequest xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#"
[03]   xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[04]   <sl:KeyboxIdentifier>CertifiedKeypair</sl:KeyboxIdentifier>

Line 4 contains the specification that a signature is to be created with the combined signature and encryption key (CertifiedKeypair).

[05]   <sl:DataObjectInfo Structure="detached">
[06]     <sl:DataObject Reference="#Para2"/>

The data item to be signed in this example is part of the document in which the signature to be created is to be inserted. The value of the Reference attribute in line 6 is #Para2, which means that the element of the parent document that has an ID attribute with the value #Para2 is to be signed. The Citizen Card Environment must validate the parent document in order to evaluate this information, as otherwise it would not know which attributes are ID attributes. In this example, a supplementary object for the parent document is used to inform the Citizen Card Environment of the XML schema required for validating parsing (see lines 31 to 36 further below).

[07]     <sl:TransformsInfo>
[08]       <dsig:Transforms>
[09]         <dsig:Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">
[10]           <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
[11]             <xsl:include href="XMLDocument.Para.xsl"/>
[12]           </xsl:stylesheet>
[13]         </dsig:Transform>
[14]         <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
[15]       </dsig:Transforms>
[16]       <sl:FinalDataMetaInfo>
[17]         <sl:MimeType>application/xhtml+xml</sl:MimeType>
[18]       </sl:FinalDataMetaInfo>

The first transformation in the example is an XSLT transformation. The style sheet specified as a child element of dsig:Transform uses xsl:include to refer to another style sheet. However, this additional style sheet cannot be resolved directly by the Citizen Card Environment, because it is specified as a relative reference. That's why it is necessary to specify this additional style sheet as a supplementary object for the data to be signed.

This additional style sheet is also a so-called implicit transformation parameter, i.e. a transformation parameter that is not included directly in the dsig:Reference of the XML signature as part of the transformation description and that is therefore not signed. Although this does not matter in many cases, it becomes important if an application subsequently attempts to verify the XML signature and if the originally referenced data (in this case the XML document) is relevant for this application rather than the resulting hash input data (in this case the resulting XHTML document). In such cases, the application can only be sure of the correct context if all the information required for the transformation of the originally referenced file to the hash input data is also signed. However, this situation no longer applies as soon as an implicit transformation parameter is used. This is why the Citizen Card Environment automatically inserts another dsig:Reference in the XML signature when implicit transformation parameters are used; this reference refers to the implicit transformation parameters which are then also signed (compare the analysis of the response further below).

[19]     </sl:TransformsInfo>
[20]     <sl:Supplement>
[21]       <sl:Content Reference="XMLDocument.Para.xsl">
[22]         <sl:LocRefContent>http://www.buergerkarte.at/konzept/securitylayer/spezifikation/\
[23]         20040514/tutorial/examples/interface/common/XMLDocument.Para.xsl</sl:LocRefContent>
[24]       </sl:Content>
[25]     </sl:Supplement>
[26]   </sl:DataObjectInfo>

A supplementary object for the data to be signed is specified in the relevant sl:DataObjectInfo element as the content of the sl:Supplement element. The mandatory sl:Content/@Reference attribute in line 21 contains the reference to the supplementary object written exactly the way in which it occurs in the xsl:include directive (line 11), in this case XMLDocument.Para.xsl. The sl:Content element contains the supplementary object as it is to be used by the Citizen Card Environment (sl:Base64Content or sl:XMLContent elements) or contains a reference to the supplementary object that can be resolved by the Citizen Card Environment (sl:LocRefContent element). In the specific example, sl:LocRefContent is used.

[27]   <sl:SignatureInfo>
[28]     <sl:SignatureEnvironment Reference="http://www.buergerkarte.at/konzept/securitylayer/\
[29]     spezifikation/20040514/tutorial/examples/interface/common/XMLDocument.withSchemaHint.xml"/>
[30]     <sl:SignatureLocation Index="4" xmlns:doc="urn:document">/doc:XMLDocument</sl:SignatureLocation>

The signature to be created should be inserted in an existing document which receives the MOA SS by resolving the URL specified in sl:SignatureEnvironment/@Reference (lines 28 and 29). The signature is to be inserted as the fifth child node of the doc:XMLDocument root element. Please note the counting method for the Index attribute and the declaration of the namespace declarations used in the XPath expression (in this case doc).

[31]     <sl:Supplement>
[32]       <sl:Content Reference="urn:XMLDocument.xsd">
[33]         <sl:LocRefContent>http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/\
[34]         tutorial/examples/interface/common/XMLDocument.xsd</sl:LocRefContent>
[35]       </sl:Content>
[36]     </sl:Supplement>
[37]   </sl:SignatureInfo>
[38] </sl:CreateXMLSignatureRequest>

As already noted above, the Citizen Card Environment must validate the parent document in order to resolve the #Para2 ID reference. The parent document contains only a reference to the required grammatical information in the form of an XML schema (attribute xsi:schemaLocation contains the value "urn:document urn:XMLDocument.xsd"). Since the urn:XMLDocument.xsd URL specified there cannot be resolved directly by the Citizen Card Environment, a supplementary object for the parent document is specified in the request (sl:Supplement, lines 31 to 36). The sl:Content/@Reference attribute in line 32 contains the reference to the supplementary object written exactly the way in which it is specified in the xsi:schemaLocation of the XML document (urn:XMLDocument.xsd). The sl:Content element contains the supplementary object as it is to be used by the Citizen Card Environment (sl:Base64Content or sl:XMLContent elements), or a reference to the supplementary object that can be resolved by the Citizen Card Environment (sl:LocRefContent element). In the specific example, sl:LocRefContent is used (lines 33 and 34).

Please note that with most Citizen Card Environments, the use of supplementary objects for conveying XML schemas only works if the reference to the XML schema in xsi:schemaLocation is an absolute URI (e.g. urn:XMLDocument.xsd as in this case, or http://example.org/XMLDocument.xsd, but not XMLDocument.xsd or ../schemas/XMLDocument.xsd for example).

Supplementary objects can also be used in the same way for resolving a reference in a DTD.

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted and shortened for better readability, although this naturally breaks the electronic signature.

In relation to the supplementary objects, the response does not contain any noteworthy special features. However, the handling of the implicit transformation parameter mentioned above by the Citizen Card Environment (additional, referenced style sheet in line 11 of the request) should be analysed.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:CreateXMLSignatureResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <doc:XMLDocument xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#"
[05]      xmlns:doc="urn:document" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 
[06]      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
[07]      xsi:schemaLocation="urn:document urn:XMLDocument.xsd">
[08]     <doc:Paragraph>Ich bin der erste Absatz in diesem Dokument.</doc:Paragraph>
[09]     <doc:Paragraph ParaId="Para2">Und ich bin der zweite Absatz in diesem Dokument.
[10] Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
[11]     <dsig:Signature Id="HS_signature" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[12]       <dsig:SignedInfo>
[13]         <dsig:CanonicalizationMethod 
[14]           Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
[15]         <dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
[16]         <dsig:Reference Id="reference-data-0" URI="#Para2">
[17]           <dsig:Transforms>
[18]             <dsig:Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">
[19]               <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
[20]                 <xsl:include href="XMLDocument.Para.xsl"/>
[21]               </xsl:stylesheet>
[22]             </dsig:Transform>
[23]             <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
[24]           </dsig:Transforms>
[25]           <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[26]           <dsig:DigestValue>luM3wUmedTvkMHVedQkA/8otXUE=</dsig:DigestValue>
[27]         </dsig:Reference>
[28]         <dsig:Reference 
[29]           Type="http://www.buergerkarte.at/specifications/Security-Layer/20020225#SignatureManifest"
[30]           URI="#Manifest">
[31]           <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[32]           <dsig:DigestValue>qCv1pfxB4ahrKCEPHRMMr5PhEAc=</dsig:DigestValue>
[33]         </dsig:Reference>
[34]         <dsig:Reference Type="http://uri.etsi.org/01903/v1.1.1#SignedProperties" URI="#refetsi">
[35]           <!--...-->
[36]         </dsig:Reference>
[37]       </dsig:SignedInfo>

It is apparent that the Citizen Card Environment has inserted a further reference to the so-called signature manifest in the dsig:SignedInfo element (lines 12 to 37) in addition to the reference to the actual data to be signed (lines 16 to 27) and the reference to the signature properties (lines 34 to 36). This special reference is identified by the special value of the Type attribute in line 29.

[38]       <dsig:SignatureValue><!--...--></dsig:SignatureValue>
[39]       <dsig:KeyInfo><!--...--></dsig:KeyInfo>
[40]       <dsig:Object>
[41]         <dsig:Manifest Id="Manifest">
[42]           <dsig:Reference URI="XMLDocument.Para.xsl">
[43]             <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[44]             <dsig:DigestValue>Ihk/yhx06oOI0Qwi57Xs9dbMW0I=</dsig:DigestValue>
[45]           </dsig:Reference>
[46]         </dsig:Manifest>
[47]       </dsig:Object>
[48]       <dsig:Object Id="refetsi"><!--...--></dsig:Object>
[49]     </dsig:Signature>
[50]   </doc:XMLDocument>
[51] </sl:CreateXMLSignatureResponse> 

The signature manifest itself can be found in a dsig:Object container in lines 40 to 47. The container contains a dsig:Manifest that contains a dsig:Reference element for every implicit transformation parameter of the XML signature used (in the specific example a dsig:Reference for the implicit transformation parameter, the additional style sheet, compare line 11 of the request or line 20 of the response). The value of the URI attribute in line 42 corresponds precisely to that of the href attribute in line 11 of the request and line 20 of the response).

Downloads for this example
Further information

2.2 Verifying signatures

2.2.1 Verifying a signature in CMS format

2.2.1.1 Initial example

Request

This example is a simple request for verifying a CMS signature. Its structure is analysed below. Please note that the following extract from the request has been shortened for the sake of clarity.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:VerifyCMSSignatureRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:CMSSignature>MIIHsAYJKoZIh...6kpOPJaLg==</sl:CMSSignature>
[05] </sl:VerifyCMSSignatureRequest>

Line 4 of the request contains the CMS signature to be verified in sl:CMSSignature in base64-encoded form. In this example, it is assumed that the signature is an Enveloping Signature, in other words the signed data forms part of the CMS structure. See the next example for an explanation of how a Detached Signature is handled.

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted and shortened for better readability.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:VerifyCMSSignatureResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#" 
[04]   xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[05]   <sl:SignerInfo>
[06]     <dsig:X509Data>
[07]       <dsig:X509SubjectName>C=AT,CN=Gregor Karlinger,S=Karlinger,G=Gregor,SN=913895552911
[08]       </dsig:X509SubjectName>
[09]       <dsig:X509IssuerSerial>
[10]         <dsig:X509IssuerName>C=AT,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr\
[11]            GmbH,OU=a-sign-Premium-Sig-01,CN=a-sign-Premium-Sig-01</dsig:X509IssuerName>
[12]         <dsig:X509SerialNumber>6218
[13]         </dsig:X509SerialNumber>
[14]       </dsig:X509IssuerSerial>
[15]       <dsig:X509Certificate>
[16] MIIE4DCCA8igAwIBAgICGEowDQYJKoZIhvcNAQEFBQAwgZcxCzAJBgNVBAYTAkFUMUgwRgYDVQQK
[17] Ez9BLVRydXN0IEdlcy4gZi4gU...Rpz2MP3nU9H2IfKk36n6hhVpc3EC6aF02RdIBD+x8VxVsA==
[18]       </dsig:X509Certificate>
[19]       <sl:QualifiedCertificate/>
[20]     </dsig:X509Data>
[21]   </sl:SignerInfo>

The response contains information about the signatory in sl:SignerInfo/dsig:X509Data (lines 5 to 21); this information is taken from the signatory certificate contained in the CMS signature.

dsig:X509SubjectName always exists and contains the name of the signatory. dsig:X509IssuerSerial also always exists and contains the name of the issuer of the signatory certificate (dsig:X509IssuerName) and the serial number of the certificate (dsig:X509SerialNumber).

The question of whether additional information about the signatory is supplied in dsig:X509Data (as in this example the signatory certificate in base64-encoded form, lines 15 to 18), depends on the Citizen Card Environment used.

The optional empty element QualifiedCertificate may also exist if the signatory certificate is a qualified certificate. This is the case in this example (cf. line 19).

[22]   <sl:SignatureCheck>
[23]     <sl:Code>0</sl:Code>
[24]     <sl:Info>Die Überprüfung des Werts der Signatur konnte erfolgreich durchgeführt\[25]        werden.</sl:Info>

[26]   </sl:SignatureCheck>

Following on from sl:SignerInfo with sl:SignatureCheck, the response contains the result of the cryptographic verification of the signature. sl:Code always exists and contains an integer code; in our example the value there is 0, i.e. the signature has been validated successfully. As an option, sl:Info may contain a text explaining the integer code.

[27]   <sl:CertificateCheck>
[28]     <sl:Code>0</sl:Code>
[29]     <sl:Info>Jedes Zertifikat dieser Kette ist zum in der Anfrage angegebenen\ [30]        Prüfzeitpunkt gültig.</sl:Info>

[31]   </sl:CertificateCheck>
[32] </sl:VerifyCMSSignatureResponse> 

Finally, the response contains the result of the signatory certificate check with sl:CertificateCheck. First the Citizen Card Environment checks whether a certificate chain can be formed to a trustworthy Trust Anchor based on the signatory certificate. If this is successful, the validity of each certificate in this chain is checked. sl:Code always exists and contains an integer code; in our example the value is 0, in other words all checks were successful. As an option, sl:Info contains a text explaining the integer code.

Downloads for this example
Further information

2.2.1.2 Extended example

Request

This extended example of the verification of a CMS signature demonstrates the checking of several signatories of a CMS signature, the specification of the time of the verification and the verification of a Detached Signature, i.e. a signature that does not contain the signed data; this data therefore has to be specified separately.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:VerifyCMSSignatureRequest Signatories="1" 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:DateTime>2004-08-17T08:00:00+02:00</sl:DateTime>
[05]   <sl:CMSSignature>MIIHiwYJKoZIhvcNAQcCoII...ccNd5OLqgkfiwsvqSk48lou</sl:CMSSignature>
[06]   <sl:DataObject>
[07]     <sl:Content>
[08]       <sl:Base64Content>RGllc2UgRGF0ZW4gd2FyZW4gYmFzZTY0IGtvZGllcnQu</sl:Base64Content>
[09]     </sl:Content>
[10]   </sl:DataObject>
[11] </sl:VerifyCMSSignatureRequest> 

If there is a CMS signature to be verified that has been signed by several signatories, the sl:VerifyCMSSignatureRequest/@Signatories attribute can be used to select the signatories whose signatures are to be verified by the Citizen Card Environment (cf. line 2). The default value for this optional attribute is 1. If the signature of the first signatory is not to be verified alone, the attribute must be specified explicitly. It contains one or more integer values, separated by blanks. Each integer identifies a signatory, with the order corresponding to the list of signatories in the CMS signature. For example, the value "1 3" would indicate that the Citizen Card Environment is to verify the signature of the first and third signatory.

The timing of the signature verification can be explicitly specified with the optional element sl:DateTime in line 4. This element contains the date and time specifications in accordance with the XML schema data type dateTime. If the specified time does not contain a time zone offset in relation to the UTC, the time is interpreted as the local time of the computer on which the Citizen Card Environment is running. If sl:DateTime is not specified, the Citizen Card Environment tries to determine the time at which the signature was created from the signature (on the basis of the SigningTime signature attribute). If the signature does not contain the time at which the signature was created, the Citizen Card Environment uses the current system time of the computer on which it is running.

The optional element sl:DataObject must be specified if a Detached Signature is to be verified, i.e. if the signed data is not to be encoded in the CMS signature. In such a case, this data is to be made available in base64-encoded form in sl:DataObject/sl:Content/sl:Base64Content (cf. lines 6 to 10).

Response

The response from the Citizen Card Environment will not be analysed in greater detail here, as it does not contain any special features relevant to the subject of the example.

Downloads for this example
Further information

2.2.2. Verifying a signature in XML format

2.2.2.1 Initial example

Request

The following is a simple XML request for verifying an XML signature. Please note that the request shown has been indented and shortened for better readability.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:VerifyXMLSignatureRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#"
[04]   xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[05]   <sl:SignatureInfo>
[06]     <sl:SignatureEnvironment>
[07]       <sl:XMLContent>
[08]         <dsig:Signature Id="signature-13122004171228295" 
[09]           xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[10]           <dsig:SignedInfo>
[11]             <dsig:CanonicalizationMethod 
[12]               Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/>
[13]             <dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
[14]             <dsig:Reference Id="reference-0-13122004171228295" 
[15]               URI="#signed-data-0-13122004171228295">
[16]               <dsig:Transforms>
[17]                 <dsig:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
[18]                   <xpf:XPath Filter="intersect" 
[19]                     xmlns:xpf="http://www.w3.org/2002/06/xmldsig-filter2">
[20]                     //*[@Id='signed-data-0-13122004171228295']/node()</xpf:XPath>
[21]                 </dsig:Transform>
[22]               </dsig:Transforms>
[23]               <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[24]               <dsig:DigestValue>pId+CwfdF8+4RdWSfPHIXeIJejA=</dsig:DigestValue>
[25]             </dsig:Reference>
[26]              ...
[27]           </dsig:SignedInfo>
[28]           <dsig:SignatureValue>...</dsig:SignatureValue>
[29]           <dsig:KeyInfo>...</dsig:KeyInfo>
[30]           <dsig:Object Id="etsi-signed-2-13122004171228295" 
[31]             xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">...</dsig:Object>
[32]           <dsig:Object Id="signed-data-0-13122004171228295">Signiere mich bitte.</dsig:Object>
[33]         </dsig:Signature>
[34]       </sl:XMLContent>
[35]     </sl:SignatureEnvironment>

The sl:SignatureInfo element (lines 5 to 37) contains the XML document to be checked, as well as details of the position of the XML signature within the XML document to be checked.

The sl:VerifySignatureEnvironment element (lines 6 to 35) contains the XML document with the XML signature to be verified. Here again various options are available for specifying this XML document. The element sl:XMLContent was used in the example; alternatively, the elements sl:Base64Content and sl:LocRefContent are available, or equal to sl:LocRefContent the attribute sl:Reference.

In this specific example, the specified XML document contains the signature to be verified (dsig:Signature) directly as a root element. This is an Enveloping Signature, i.e. the signed data is encoded in a dsig:Object as part of the XML structure of the signature. The string Signiere mich bitte. is actually signed here.

[36]     <sl:SignatureLocation>/dsig:Signature</sl:SignatureLocation>
[37]   </sl:SignatureInfo>
[38] </sl:VerifyXMLSignatureRequest>

The sl:SignatureLocation element contains the text of the XPath expression for selecting the XML signature within the XML document to be checked. The evaluation of the XPath expression must yield precisely one element – dsig:Signature. Please note that in the context of the sl:SignatureLocation element, all namespace prefixes used in the XPath expression must be known (in this case the dsig prefix, declared in line 4 of the request).

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted and shortened for better readability.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:VerifyXMLSignatureResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#" 
[04]   xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[05]   <sl:SignerInfo>
[06]     <dsig:X509Data>
[07]       <dsig:X509SubjectName>C=AT,CN=Gregor Karlinger,S=Karlinger,G=Gregor,SN=913895552911
[08]       </dsig:X509SubjectName>
[09]       <dsig:X509IssuerSerial>
[10]         <dsig:X509IssuerName>C=AT,O=A-Trust Ges. f. Sicherheitssysteme im elektr. \
[11]           Datenverkehr GmbH,OU=a-sign-Premium-Sig-01,CN=a-sign-Premium-Sig-01
[12]         </dsig:X509IssuerName>
[13]         <dsig:X509SerialNumber>6218</dsig:X509SerialNumber>
[14]       </dsig:X509IssuerSerial>
[15]       <dsig:X509Certificate>MIIE4DCCA8ig...c3EC6aF02RdIBD+x8VxVsA==</dsig:X509Certificate>
[16]       <sl:QualifiedCertificate/>
[17]     </dsig:X509Data>
[18]   </sl:SignerInfo>

First the response contains details of the signatory in sl:SignerInfo (lines 5 to 18).

If during signature verification the Citizen Card Environment succeeded in identifying an X.509 signatory certificate corresponding to the public key, sl:SignerInfo contains precisely one dsig:X509Data element that has the following structure: dsig:X509SubjectName always exists and contains the name of the signatory. dsig:X509IssuerSerial also always exists and contains the name of the issuer of the signatory certificate (dsig:X509IssuerName) and the serial number of the certificate (dsig:X509SerialNumber). The optional empty element QualifiedCertificate may also exist if the signatory certificate is a qualified certificate. This is the case in this example (cf. line 16). The question of whether additional information about the signatory is supplied in dsig:X509Data (as in this example the signatory certificate in base64-encoded form, line 15) depends on the Citizen Card Environment used.

[19]   <sl:SignatureCheck>
[20]     <sl:Code>0</sl:Code>
[21]     <sl:Info>Die Überprüfung der Hash-Werte und des Werts der Signatur konnte erfolgreich \[22]       durchgeführt werden.</sl:Info>

[23]   </sl:SignatureCheck>

Following on from sl:SignerInfo, the response contains the result of the cryptographic verification of the signature with sl:SignatureCheck. sl:Code always exists and contains an integer code; in our example the value there is 0, i.e. the signature has been validated successfully. As an option sl:Info may contain a text explaining the integer code.

[24]   <sl:SignatureManifestCheck>
[25]     <sl:Code>0</sl:Code>
[26]     <sl:Info>Für diese Signatur ist kein Signaturmanifest notwendig.</sl:Info>
[27]   </sl:SignatureManifestCheck>

After this, the response contains the result of the signature manifest check with sl:SignatureManifestCheck. sl:Code always exists and contains an integer code; in our example the value there is 0, i.e. the signature to be verified does not require a signature manifest. As an option, sl:Info may contain a text explaining the integer code.

[28]   <sl:CertificateCheck>
[29]     <sl:Code>0</sl:Code>
[30]     <sl:Info>Jedes Zertifikat dieser Kette ist zum in der Anfrage angegebenen Prüfzeitpunkt \[31]       gültig.</sl:Info>

[32]   </sl:CertificateCheck>
[33] </sl:VerifyXMLSignatureResponse>

Finally, the response contains the result of the signatory certificate check with sl:CertificateCheck. First the Citizen Card Environment checks whether a certificate chain can be formed to a trustworthy Trust Anchor based on the signatory certificate. If this is successful, the validity of each certificate in this chain is checked. sl:Code always exists and contains an integer code; in our example the value is 0, in other words all checks were successful. As an option, sl:Info contains a text explaining the integer code.

Downloads for this example
Further information

2.2.2.2 Extended example

Request

This extended example for verifying an XML signature shows the explicit indication of the test time and the specification of the XML document with the signature to be verified by means of a reference.

[01]<?xml version="1.0" encoding="UTF-8"?>
[02] <sl:VerifyXMLSignatureRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#" 
[04]   xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[05]   <sl:DateTime>2004-12-13T17:00:00</sl:DateTime>

The timing of the signature verification can be explicitly specified with the optional element sl:DateTime in line 5. This element contains the date and time specifications in accordance with the XML schema data type dateTime. If the specified time does not contain a time zone offset in relation to the UTC, the time is interpreted as the local time of the computer on which the Citizen Card Environment is running. If sl:DateTime is not specified, the Citizen Card Environment tries to determine the time at which the signature was created from the signature (on the basis of the SigningTime signature attribute). If the signature does not contain the time at which the signature was created, the Citizen Card Environment uses the current system time of the computer on which it is running.

[06]   <sl:SignatureInfo>
[07]     <sl:SignatureEnvironment Reference="http://www.buergerkarte.at/konzept/securitylayer/ \
[08]       spezifikation/20040514/tutorial/examples/interface/common/XMLDocument.signed.xml"/>
[09]     <sl:SignatureLocation 
[10]       xmlns:doc="urn:Document">/doc:Document/dsig:Signature</sl:SignatureLocation>
[11]   </sl:SignatureInfo>
[12] </sl:VerifyXMLSignatureRequest>

The XML document containing the XML signature to be verified is not specified directly as content in sl:SignatureEnvironment/sl:XMLContent or sl:SignatureEnvironment/sl:Base64Content in this case, but instead this document is simply referenced by URL (compare the value of the Reference attribute in lines 7 and 8). The Citizen Card Environment will resolve this URL in order to retrieve the XML document with the XML signature to be verified.

The sl:SignatureLocation element (lines 9 and 10) contains the text of the XPath expression for selecting the XML signature within the XML document to be checked. The evaluation of the XPath expression must yield precisely one element – dsig:Signature. Please note that in the context of the sl:SignatureLocation element, all namespace prefixes used in the XPath expression must be known (in this case the dsig prefix, declared in line 4 of the request, or doc, declared in line 10 of the request).

Response

The response from the Citizen Card Environment will not be analysed in greater detail here, as it does not contain any special features relevant to the subject of the example.

Downloads for this example
Further information

2.2.2.3 Checking XMLDSIG manifests

Request

This example of the verification of an XML signature demonstrates the checking of an XMLDSIG manifest contained in the XML signature. Please note that the request shown has been indented and shortened for better readability.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <VerifyXMLSignatureRequest 
[03]   xmlns="http://www.buergerkarte.at/namespaces/securitylayer/1.2#" 
[04]   xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[05]   <SignatureInfo>
[06]     <SignatureEnvironment>
[07]       <XMLContent>
[08]         <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Id="signature-1-1">
[09]           <dsig:SignedInfo>
[10]             <dsig:CanonicalizationMethod 
[11]               Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
[12]             <dsig:SignatureMethod 
[13]               Algorithm="http://www.buergerkarte.at/namespaces/ecdsa/200206030#ecdsa-sha1"/>
[14]             <dsig:Reference Type="http://www.w3.org/2000/09/xmldsig#Manifest" 
[15]               URI="#dsig-manifest-1-1">
[16]               <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[17]               <dsig:DigestValue>nUUaW6OtcsNvV/QhqmkU2QXT1Mw=</dsig:DigestValue>
[18]             </dsig:Reference>
[19]           </dsig:SignedInfo>
[20]           <dsig:SignatureValue>...</dsig:SignatureValue>
[21]           <dsig:KeyInfo>...</dsig:KeyInfo>
[22]           <dsig:Object Id="signed-data-1-1-1">Diese Daten sind signiert.</dsig:Object>
[23]           <dsig:Object>
[24]             <dsig:Manifest Id="dsig-manifest-1-1">
[25]               <dsig:Reference Id="reference-1-1" 
[26]                 URI="#xpointer(id('signed-data-1-1-1')/node())">
[27]                 <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[28]                 <dsig:DigestValue>EYxznGxNRAIcHQeUsj+zsK+uaHA=</dsig:DigestValue>
[29]               </dsig:Reference>
[30]             </dsig:Manifest>
[31]           </dsig:Object>
[32]         </dsig:Signature>
[33]       </XMLContent>
[34]     </SignatureEnvironment>

The sl:SignatureEnvironment element (lines 6 to 34) contains the XML signature to be verified as sl:XMLContent. It is evident that the only dsig:Reference in the dsig:SignedInfo of the XML signature (lines 14 to 18) refers to an XMLDSig manifest (apparent in the Type attribute in line 14, which is set to the value http://www.w3.org/2000/09/xmldsig#Manifest). Thus, we receive a separate result for the manifest check in the response (see below).

The manifest itself is encoded in a dsig:Object, in other words within the XML structure of the XML signature (lines 24 to 30). It contains a dsig:Reference (lines 25 to 29) that relates to the string Diese Daten sind signiert. (line 22).

[35]     <SignatureLocation>//dsig:Signature</SignatureLocation>
[36]   </SignatureInfo>
[37] </VerifyXMLSignatureRequest> 

The sl:SignatureLocation element (line 35) contains the text of the XPath expression for selecting the XML signature within the XML document to be checked. The evaluation of the XPath expression must yield precisely one element – dsig:Signature. Please note that in the context of the sl:SignatureLocation element, all namespace prefixes used in the XPath expression must be known (in this case the dsig prefix, declared in line 4 of the request).

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted and shortened for better readability.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:VerifyXMLSignatureResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#" 
[04]   xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[05]   <sl:SignerInfo>
[06]     <dsig:X509Data>...</dsig:X509Data>
[07]   </sl:SignerInfo>
[08]   <sl:SignatureCheck>...</sl:SignatureCheck>
[09]   <sl:SignatureManifestCheck>...</sl:SignatureManifestCheck>

The response contains information about the signatory in sl:SignerInfo/dsig:X509Data; this information is taken from the signatory certificate contained in the XML signature. The sl:SignatureCheck element contains the result of the cryptographic verification of the signature; the sl:SignatureManifestCheck element contains the result of the signature manifest check.

[10]   <sl:XMLDSIGManifestCheck>
[11]     <sl:Code>0</sl:Code>
[12]     <sl:Info>Für jede dsig:Reference des mittels sl:Info näher gekennzeichneten Manifests \[13]       konnte der Hash-Wert erfolgreich überprüft werden.

[14]       <sl:ReferringSigReference>1</sl:ReferringSigReference>
[15]     </sl:Info>
[16]   </sl:XMLDSIGManifestCheck>

sl:XMLDSIGManifestCheck (lines 10 to 16) is a new element in this response and follows on from sl:SignatureCheck. One or more of these elements is always returned if there are dsig:Reference elements in dsig:SignedInfo of the XML signature, which relate to an XMLDSIG manifest (see above). For each such dsig:Reference, the response contains a corresponding sl:XMLDSIGManifestCheck element, in this specific example one.

The sl:Code element specifies the result of the XMLDSIG manifest check. sl:Code always exists and contains an integer code; in our example the value there is 0, i.e. every dsig:Reference in the dsig:Manifest (in this particular example precisely one dsig:Reference) has been checked successfully. As an option, sl:Info may contain a text explaining the integer code.

The sl:Info/sl:ReferringSigReference element contains a text with the number of the dsig:Reference element in dsig:SignedInfo of the XML signature that refers to the analysed XMLDSIG manifest; counting starts at 1. In this example it was the first dsig:Reference.

[17]   <sl:CertificateCheck>...</sl:CertificateCheck>
[18] </sl:VerifyXMLSignatureResponse>

The sl:CertificateCheck contains the result of the certificate check.

Downloads for this example
Further information

2.2.2.4 Supplementary objects

Request

This example of the verification of an XML signature demonstrates how supplementary objects are used. A supplementary object relates either to a signed data item (see dsig:Reference of the XML signature) or to the document containing the XML signature to be verified (see sl:SignatureEnvironment). It must be specified if reference is made to a signed data item, or to other data within a signed data item or in the XML document containing the XML signature, but this reference cannot be resolved by the Citizen Card Environment. The supplementary object contains precisely this data that cannot be resolved by the Citizen Card Environment.

Please note that the request shown has been indented and shortened for better readability.

[001] <?xml version="1.0" encoding="UTF-8"?>
[002] <sl:VerifyXMLSignatureRequest 
[003]   xmlns=sl:"http://www.buergerkarte.at/namespaces/securitylayer/1.2#" 
[004]   xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[005]   <sl:SignatureInfo>
[006]     <sl:SignatureEnvironment>
[007]       <sl:XMLContent>
[008]         <doc:XMLDocument 
[009]           xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
[010]           xmlns:doc="urn:document" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
[011]           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
[012]           xsi:schemaLocation="urn:document urn:XMLDocument.xsd">
[013]           <doc:Paragraph>Ich bin der erste Absatz in diesem Dokument.</doc:Paragraph>
[014]           <doc:Paragraph ParaId="Para2">Und ich bin der zweite Absatz in diesem Dokument.
[015]             Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
[016]           <dsig:Signature Id="signature-1-1" 
[017]             xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">

The sl:SignatureEnvironment element (line 6 et seq.) contains the XML document (doc:XMLDocument, line 8 et seq.) with the XML signature to be verified (line 16 et seq.).

[018]             <dsig:SignedInfo>
[019]               ...
[020]               <dsig:Reference Id="reference-1-1" URI="SimpleText.txt">
[021]                 <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[022]                 <dsig:DigestValue>7Dp/5KcvUfCnkohkOOzvFaeAIRc=</dsig:DigestValue>
[023]               </dsig:Reference>

The first dsig:Reference of the XML signature to be verified (lines 20 to 23) uses the SimpleText.txt URL to refer to an external document. Since the URI in question is a relative URI, the Citizen Card Environment will not be able to resolve it, which means that a corresponding supplement will have to be specified (see below).

[024]               <dsig:Reference Id="reference-1-2" URI="#Para2">
[025]                 <dsig:Transforms>
[026]                   <dsig:Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">
[027]                     <xsl:stylesheet 
[028]                       version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
[029]                       <xsl:include href="XMLDocument.Para.xsl"/>
[030]                     </xsl:stylesheet>
[031]                   </dsig:Transform>
[032]                   <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
[033]                 </dsig:Transforms>
[034]                 <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[035]                 <dsig:DigestValue>luM3wUmedTvkMHVedQkA/8otXUE=</dsig:DigestValue>
[036]               </dsig:Reference>
[037]               ...
[038]             </dsig:SignedInfo>
[039]             <dsig:SignatureValue>...</dsig:SignatureValue>
[040]             <dsig:KeyInfo>...</dsig:KeyInfo>
[041]             ...
[042]           </dsig:Signature>
[043]         </doc:XMLDocument>
[044]       </sl:XMLContent>
[045]     </sl:SignatureEnvironment>
[046]     <sl:SignatureLocation>//dsig:Signature</sl:SignatureLocation>
[047]   </sl:SignatureInfo>

It is apparent that the URI attribute of the second dsig:Reference of the signature to be verified (lines 24 to 36) contains an internal reference to the doc:Paragraph element with the ParaId ID attribute set to Para2 (cf. line 14 further above). However, the Citizen Card Environment can only recognise the fact that doc:Paragraph/@ParaId is an ID attribute if it validates the XML document. Although the required reference to the corresponding XML schema exists with the xsi:schemaLocation attribute (cf. line 12 further above), with urn:XMLDocument.xsd, it is a non-resolvable reference. This is why a corresponding supplementary object is required in the request (see below).

It is also evident that dsig:Reference contains an XSLT transformation (lines 26 to 31). The style sheet parameter encoded here (dsig:Transform/xsl:stylesheet) includes another style sheet (XMLDocument.Para.xsl, cf. line 29). However, this reference cannot be resolved for the Citizen Card Environment. Here again a corresponding supplementary object is required (see below).

[048]   <sl:Supplement>
[059]     <sl:Content Reference="SimpleText.txt">
[050]       <sl:XMLContent>I am a simple text.</sl:XMLContent>
[051]     </sl:Content>
[052]   </sl:Supplement>

The first element sl:Supplement contains the supplementary object for the external text document described above (cf. lines 20 to 23). sl:Content/@Reference contains the reference in precisely the form in which it was specified earlier in the URI attribute of the dsig:Reference. sl:Content either explicitly contains the data to be used by the Citizen Card Environment instead of resolving the reference (sl:Base64Content or – as in this particular example – sl:XMLContent), or alternatively, a resolvable reference for this data is transmitted to the Citizen Card Environment with sl:LocRefContent.

[053]   <sl:Supplement>
[054]     <sl:Content Reference="XMLDocument.Para.xsl">
[055]       <sl:XMLContent>
[056]         <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
[057]           xmlns:doc="urn:document" xmlns="http://www.w3.org/1999/xhtml">
[058]           <xsl:output encoding="UTF-8" method="xml" indent="yes"/>
[059]           <xsl:template match="/">
[060]             <html xmlns="http://www.w3.org/1999/xhtml">
[061]               <head>
[062]                 <title>HTML document</title>
[063]               </head>
[064]               <body>
[065]                 <xsl:apply-templates/>
[066]               </body>
[067]             </html>
[068]           </xsl:template>
[069]           <xsl:template match="doc:Paragraph">
[070]             <p>
[071]               <xsl:value-of select="child::text()"/>
[072]             </p>
[073]           </xsl:template>
[074]         </xsl:stylesheet>
[075]       </sl:XMLContent>
[076]     </sl:Content>
[077]   </sl:Supplement>

The second element sl:Supplement contains the supplementary object for the incorporated style sheet described above (cf. line 29). sl:Content/@Reference contains the reference in precisely the form in which it was specified earlier in the xsl:stylesheet/@href attribute. sl:Content either explicitly contains the data to be used by the Citizen Card Environment instead of resolving the reference (sl:Base64Content or – as in this particular example – sl:XMLContent), or alternatively, a resolvable reference for this data is transmitted to the Citizen Card Environment with sl:LocRefContent.

[078]   <sl:Supplement>
[079]     <sl:Content Reference="urn:XMLDocument.xsd">
[080]       <sl:XMLContent>
[081]         <xs:schema targetNamespace="urn:document" 
[082]           xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:document" 
[083]           elementFormDefault="qualified" attributeFormDefault="unqualified">
[084]           <xs:element name="XMLDocument">
[085]             <xs:complexType>
[086]               <xs:sequence>
[087]                 <xs:element name="Paragraph" maxOccurs="unbounded">
[088]                   <xs:complexType mixed="true">
[089]                     <xs:attribute name="ParaId" type="xs:ID" use="optional"/>
[090]                   </xs:complexType>
[091]                 </xs:element>
[092]                 <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"
[093]                   processContent="lax"/>
[094]               </xs:sequence>
[095]             </xs:complexType>
[096]           </xs:element>
[097]         </xs:schema>
[098]       </sl:XMLContent>
[099]     </sl:Content>
[100]   </sl:Supplement>
[101] </sl:VerifyXMLSignatureRequest>

As before, the third element sl:Supplement contains the supplementary object for the XML schema described above. Content/@Reference in line 79 contains the reference in precisely the form in which it was specified in line 12 in the xsi:schemaLocation attribute.

Response

The response from the Citizen Card Environment will not be analysed in greater detail here, as it does not contain any special features relevant to the subject of the example.

Downloads for this example
Further information

2.3 Data encryption

2.3.1 Data encryption using the CMS standard

2.3.1.1 CMS encryption using base64 encoded data

Request

The text fragment Ich bin ein einfacher Text. should be encrypted for selected recipients. The public keys of the recpients are needed for the encryption process (element RecipientPublicKey). A public key is contained in the X509 certificate of a receiver and is stored in the element X509Certificate. Such an element is needed for each recipient. In this example there is only one recipient.

The base64 encoded data which needs to be encrypted is given in the element sl:ToBeEncrytped/sl:Content/sl:Base64Content.

Furthermore, the element sl:ToBeEncrypted contains meta information which provides further information about the encrypted data. The element sl:ToBeEncrypted/sl:MetaIndo/sl:MimeType is mandatory and contains information which is used by the viewer of the Citizen Card Environment for displaying the data. The optional element sl:ToBeEncrypted/sl:MetaInfo/sl:Description can be used to describe the data which should be encrypted.

[01]  <?xml version="1.0" encoding="UTF-8"?>
[02]    <sl:EncryptCMSRequest
[03]      xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">      
[04]      <sl:RecipientPublicKey>
[05]        <sl:X509Certificate>
[06]          MIIFBDCCA+ygAwIBAgIDASpYMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJBVDFIMEYGA1UE
[07]          Cgw/QS1UcnVzdCBHZXMuIGYuIFNpY2hlcmhlaXRzc3lzdGVtZSBpbSBlbGVrdHIuIERhdGVudmVy
[08]          a2VociBHbWJIMR4wHAYDVQQLDBVhLXNpZ24tUHJlbWl1bS1FbmMtMDIxHjAcBgNVBAMMFWEtc2ln
[09]          bi1QcmVtaXVtLUVuYy0wMjAeFw0wNTA0MjEwNjE0MzdaFw0wOTA0MjEwNjE0MzdaMFoxCzAJBgNV
[10]          BAYTAkFUMRQwEgYDVQQDDAtQZXRlciBUZXVmbDEOMAwGA1UEBAwFVGV1ZmwxDjAMBgNVBCoMBVBl
[11]          dGVyMRUwEwYDVQQFEww2NjcxOTI1NzA2MzQwgd8wDQYJKoZIhvcNAQEBBQADgc0AMIHJAoHBALzp
[12]          AKja0OI2iGC+ufp8hMYo/U1iAjIY/HcOgIb+UN+0qL4RmGEt1CTYBcm6t3NIGi9+pVTat0nKmSsH
[13]          qs5NtlZJvahIHrs6q/Nvs6vzLTVHkRwl9CcgsF54MdKz/LzE41yZ+EE07HqW8l69OIXNSVrFS4kG
[14]          oEJUHFGWdke71Kpbfu4+2d2cfU9jMX/rUzBz/fcbeg2IMY3DhI4uH7R492eS5bEmbZnYlSuvK4Em
[15]          3Mx3TFrL8ZOjNOCnfJAuAbf9gwIDAQABo4IB1zCCAdMwEwYDVR0jBAwwCoAIRyFHjpdh4x4wewYI
[16]          KwYBBQUHAQEEbzBtMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LmEtdHJ1c3QuYXQvY2VydHMvYS1z
[17]          aWduLVByZW1pdW0tRW5jLTAyYS5jcnQwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmEtdHJ1c3Qu
[18]          YXQvb2NzcDBNBgNVHSAERjBEMEIGBiooABEBDDA4MDYGCCsGAQUFBwIBFipodHRwOi8vd3d3LmEt
[19]          dHJ1c3QuYXQvZG9jcy9jcC9hLXNpZ24tdG9rZW4wgZoGA1UdHwSBkjCBjzCBjKCBiaCBhoaBg2xk
[20]          YXA6Ly9sZGFwLmEtdHJ1c3QuYXQvb3U9YS1zaWduLVByZW1pdW0tRW5jLTAyLG89QS1UcnVzdCxj
[21]          PUFUP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q/YmFzZT9vYmplY3RjbGFzcz1laWRDZXJ0aWZp
[22]          Y2F0aW9uQXV0aG9yaXR5MBEGA1UdDgQKBAhEc3YCuoW7uDAOBgNVHQ8BAf8EBAMCBLAwJQYDVR0R
[23]          BB4wHIEacGV0ZXIudGV1ZmxAaWFpay50dWdyYXouYXQwCQYDVR0TBAIwADANBgkqhkiG9w0BAQUF
[24]          AAOCAQEAJfg2cBaLMaXVqoZ23UA8qKxTxh+WeSlEveI4Ca43tu89uutJ3w/rXVFJ1EcSaA4OTAJt
[25]          icp5LstzJmrJoTcxbb3gC46x5MrgyvDbiTb/AiHBw11C0GN3pjv1cqFfOMYvuWPb1iVPgCdCYqva
[26]          sr5KNWbge9r0tEh6Oogx0zAVrsdSYN30eSECch6NKlptD6L5KRKoorlCIBq7n2U70DpSWFYQHegJ
[27]          ier2yeY5hG6ceIZKKJ/fjDLH2NzWidoXk3NWqc3X836YCnoNyQ0oqgkz6gPSyWTpWnJ+j/WNBouA
[28]          ImEAiehOOgnNBJgS72z5iJsDFcLfI6cX/WmibSp3nR/AMQ==
[29]        </sl:X509Certificate>
[30]      </sl:RecipientPublicKey>
[31]    <sl:ToBeEncrypted>
[32]    <sl:MetaInfo>
[33]      <sl:MimeType>
[34]        text/plain
[35]	  </sl:MimeType>
[36]      <sl:Description>
[37]            Diese Daten liegen als reiner Text vor.
[38]	   </sl:Description>
[39]    </sl:MetaInfo>
[40]    <sl:Content>	
[41]      <sl:Base64Content>
[42]        SWNoIGJpbiBlaW4gZWluZmFjaGVyIFRleHQu
[43]      </sl:Base64Content>
[44]    </sl:Content>	
[45]    </sl:ToBeEncrypted>
[46]  </sl:EncryptCMSRequest>

Line 2 contains the relevant command of the Security Layer interface.

Line 3 contains the name space declaration for the XML elements that comprise the request.

Lines 4 to 30 contain the base64 encoded X509 certificate of the recipient.

Lines 32 to 39 contain meta information required by the viewer for displaying the data which should to be encrypted.

Lines 40 to 44 contain the data which should be encrypted (this is the base64 encoded text fragment Ich bin ein einfacher Text).


Response
The response contains the CMS encrypted data in the element CMSMessage.
[01]  <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
[02]  <sl:EncryptCMSResponse 
[03]    xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]    <sl:CMSMessage>
[05]      MIIB3AYJKoZIhvcNAQcDoIIBzTCCAckCAQExggF7MIIBdwIBATCBnzCBlzEL
[06]      MAkGA1UEBhMCQVQxSDBGBgNVBAoMP0EtVHJ1c3QgR2VzLiBmLiBTaWNoZXJo
[07]      ZWl0c3N5c3RlbWUgaW0gZWxla3RyLiBEYXRlbnZlcmtlaHIgR21iSDEeMBwG
[08]      A1UECwwVYS1zaWduLVByZW1pdW0tRW5jLTAyMR4wHAYDVQQDDBVhLXNpZ24t
[09]      UHJlbWl1bS1FbmMtMDICAwEqWDANBgkqhkiG9w0BAQEFAASBwBiwSIHzq6LK
[10]      4RcT6wrA6TuJAHgsVRtirQQhMkvgSWyozC5SJoyYDVuqFgci+0MwBioPp7H6
[11]      gv0m2RAp3p7MdyaUBY7WzC9X5anTcioCuI1E4EoQJGyg+rUD7PzrRl/HroP3
[12]      EEzGK7jZCJ9ToWmleMMYsLmtkMJ5MlnRdtyuReLU8ATfGCJOMSJlUDuiVqmU
[13]      UOSO/l8M6AyXz7ZJ7ntgf6IJtOo0G/f5Ph/smWWXltKD2nWxzJUUaXs75lfB
[14]      +/KfTjBFBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECPEnrwVJxQ54oCIEIBcB
[15]      bbIEsKpuWsUxFFPBBjTJtV8rVFXfpTBFuC03ltTo
[16]    </sl:CMSMessage>
[17]   </sl:EncryptCMSResponse>

Line 2 contains the relevant response of the Security Layer interface.

Line 3 contains the name space declaration for the XML elements that comprise the request.

Lines 4 to 16 contain the base64 encoded CMS message.

Downloads for this example
Further information

2.3.1.2 CMS encryption using a reference

Request

This example uses a reference to point to the data which should be encrypted. The reference is stored in the attribute sl:ToBeEncrypted/sl:Content/@Reference. The other elements are the same as in the request shown in 2.3.1.1.

[01]  <?xml version="1.0" encoding="UTF-8"?>
[02]    <sl:EncryptCMSRequest
[03]      xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">      
[04]      <sl:RecipientPublicKey>
[05]        <sl:X509Certificate>
[06]          MIIFBDCCA+ygAwIBAgIDASpYMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJBVDFIMEYGA1UE
[07]          Cgw/QS1UcnVzdCBHZXMuIGYuIFNpY2hlcmhlaXRzc3lzdGVtZSBpbSBlbGVrdHIuIERhdGVudmVy
[08]          a2VociBHbWJIMR4wHAYDVQQLDBVhLXNpZ24tUHJlbWl1bS1FbmMtMDIxHjAcBgNVBAMMFWEtc2ln
[09]          bi1QcmVtaXVtLUVuYy0wMjAeFw0wNTA0MjEwNjE0MzdaFw0wOTA0MjEwNjE0MzdaMFoxCzAJBgNV
[10]          BAYTAkFUMRQwEgYDVQQDDAtQZXRlciBUZXVmbDEOMAwGA1UEBAwFVGV1ZmwxDjAMBgNVBCoMBVBl
[11]          dGVyMRUwEwYDVQQFEww2NjcxOTI1NzA2MzQwgd8wDQYJKoZIhvcNAQEBBQADgc0AMIHJAoHBALzp
[12]          AKja0OI2iGC+ufp8hMYo/U1iAjIY/HcOgIb+UN+0qL4RmGEt1CTYBcm6t3NIGi9+pVTat0nKmSsH
[13]          qs5NtlZJvahIHrs6q/Nvs6vzLTVHkRwl9CcgsF54MdKz/LzE41yZ+EE07HqW8l69OIXNSVrFS4kG
[14]          oEJUHFGWdke71Kpbfu4+2d2cfU9jMX/rUzBz/fcbeg2IMY3DhI4uH7R492eS5bEmbZnYlSuvK4Em
[15]          3Mx3TFrL8ZOjNOCnfJAuAbf9gwIDAQABo4IB1zCCAdMwEwYDVR0jBAwwCoAIRyFHjpdh4x4wewYI
[16]          KwYBBQUHAQEEbzBtMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LmEtdHJ1c3QuYXQvY2VydHMvYS1z
[17]          aWduLVByZW1pdW0tRW5jLTAyYS5jcnQwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmEtdHJ1c3Qu
[18]          YXQvb2NzcDBNBgNVHSAERjBEMEIGBiooABEBDDA4MDYGCCsGAQUFBwIBFipodHRwOi8vd3d3LmEt
[19]          dHJ1c3QuYXQvZG9jcy9jcC9hLXNpZ24tdG9rZW4wgZoGA1UdHwSBkjCBjzCBjKCBiaCBhoaBg2xk
[20]          YXA6Ly9sZGFwLmEtdHJ1c3QuYXQvb3U9YS1zaWduLVByZW1pdW0tRW5jLTAyLG89QS1UcnVzdCxj
[21]          PUFUP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q/YmFzZT9vYmplY3RjbGFzcz1laWRDZXJ0aWZp
[22]          Y2F0aW9uQXV0aG9yaXR5MBEGA1UdDgQKBAhEc3YCuoW7uDAOBgNVHQ8BAf8EBAMCBLAwJQYDVR0R
[23]          BB4wHIEacGV0ZXIudGV1ZmxAaWFpay50dWdyYXouYXQwCQYDVR0TBAIwADANBgkqhkiG9w0BAQUF
[24]          AAOCAQEAJfg2cBaLMaXVqoZ23UA8qKxTxh+WeSlEveI4Ca43tu89uutJ3w/rXVFJ1EcSaA4OTAJt
[25]          icp5LstzJmrJoTcxbb3gC46x5MrgyvDbiTb/AiHBw11C0GN3pjv1cqFfOMYvuWPb1iVPgCdCYqva
[26]          sr5KNWbge9r0tEh6Oogx0zAVrsdSYN30eSECch6NKlptD6L5KRKoorlCIBq7n2U70DpSWFYQHegJ
[27]          ier2yeY5hG6ceIZKKJ/fjDLH2NzWidoXk3NWqc3X836YCnoNyQ0oqgkz6gPSyWTpWnJ+j/WNBouA
[28]          ImEAiehOOgnNBJgS72z5iJsDFcLfI6cX/WmibSp3nR/AMQ==
[29]        </sl:X509Certificate>
[30]      </sl:RecipientPublicKey>
[31]    <sl:ToBeEncrypted>
[32]      <sl:MetaInfo>
[33]        <sl:MimeType>
[34]          text/html
[35]	    </sl:MimeType>
[36]       <sl:Description>
[37]         Diese Daten liegen als reiner Text vor.
[38]       </sl:Description>
[39]      </sl:MetaInfo>
[40]      <sl:Content
[41]        Reference="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/aktuell/tutorial/Tutorial.html">
[42]      </sl:Content>
[43]    </sl:ToBeEncrypted>
[44]  </sl:EncryptCMSRequest>
Response

Except for the encrypted data, the response corresponds to the response of 2.3.1.1.

Downloads for this example
Further information

2.3.2 Data encryption using the XMLENC standard

2.3.2.1 Encryption of a complete XML document (New)

Request

The element NEW is used when XML documents or arbitrary data need to be encrypted according to the XMLENC standard. There are three different methods to provide the data which should be encrypted:

The following example shows how to encrypt a complete XML Dokument, which is contained in the element XMLContent.

[01]  <?xml version="1.0" encoding="UTF-8"?>
[02]  <sl:EncryptXMLRequest
[03]    xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#"
[04]    xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
[05]    xmlns:docns="http://www.w3.org/1999/xhtml">
[06]    <sl:RecipientPublicKey>
[07]      <sl:X509Certificate>
[08]        MIIFBDCCA+ygAwIBAgIDASpYMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJBVDFIMEYGA1UE
[09]        Cgw/QS1UcnVzdCBHZXMuIGYuIFNpY2hlcmhlaXRzc3lzdGVtZSBpbSBlbGVrdHIuIERhdGVudmVy
[10]        a2VociBHbWJIMR4wHAYDVQQLDBVhLXNpZ24tUHJlbWl1bS1FbmMtMDIxHjAcBgNVBAMMFWEtc2ln
[11]        bi1QcmVtaXVtLUVuYy0wMjAeFw0wNTA0MjEwNjE0MzdaFw0wOTA0MjEwNjE0MzdaMFoxCzAJBgNV
[12]        BAYTAkFUMRQwEgYDVQQDDAtQZXRlciBUZXVmbDEOMAwGA1UEBAwFVGV1ZmwxDjAMBgNVBCoMBVBl
[13]        dGVyMRUwEwYDVQQFEww2NjcxOTI1NzA2MzQwgd8wDQYJKoZIhvcNAQEBBQADgc0AMIHJAoHBALzp
[14]        AKja0OI2iGC+ufp8hMYo/U1iAjIY/HcOgIb+UN+0qL4RmGEt1CTYBcm6t3NIGi9+pVTat0nKmSsH
[15]        qs5NtlZJvahIHrs6q/Nvs6vzLTVHkRwl9CcgsF54MdKz/LzE41yZ+EE07HqW8l69OIXNSVrFS4kG
[16]        oEJUHFGWdke71Kpbfu4+2d2cfU9jMX/rUzBz/fcbeg2IMY3DhI4uH7R492eS5bEmbZnYlSuvK4Em
[17]        3Mx3TFrL8ZOjNOCnfJAuAbf9gwIDAQABo4IB1zCCAdMwEwYDVR0jBAwwCoAIRyFHjpdh4x4wewYI
[18]        KwYBBQUHAQEEbzBtMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LmEtdHJ1c3QuYXQvY2VydHMvYS1z
[19]        aWduLVByZW1pdW0tRW5jLTAyYS5jcnQwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmEtdHJ1c3Qu
[20]        YXQvb2NzcDBNBgNVHSAERjBEMEIGBiooABEBDDA4MDYGCCsGAQUFBwIBFipodHRwOi8vd3d3LmEt
[21]        dHJ1c3QuYXQvZG9jcy9jcC9hLXNpZ24tdG9rZW4wgZoGA1UdHwSBkjCBjzCBjKCBiaCBhoaBg2xk
[22]        YXA6Ly9sZGFwLmEtdHJ1c3QuYXQvb3U9YS1zaWduLVByZW1pdW0tRW5jLTAyLG89QS1UcnVzdCxj
[23]        PUFUP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q/YmFzZT9vYmplY3RjbGFzcz1laWRDZXJ0aWZp
[24]        Y2F0aW9uQXV0aG9yaXR5MBEGA1UdDgQKBAhEc3YCuoW7uDAOBgNVHQ8BAf8EBAMCBLAwJQYDVR0R
[25]        BB4wHIEacGV0ZXIudGV1ZmxAaWFpay50dWdyYXouYXQwCQYDVR0TBAIwADANBgkqhkiG9w0BAQUF
[26]        AAOCAQEAJfg2cBaLMaXVqoZ23UA8qKxTxh+WeSlEveI4Ca43tu89uutJ3w/rXVFJ1EcSaA4OTAJt
[27]        icp5LstzJmrJoTcxbb3gC46x5MrgyvDbiTb/AiHBw11C0GN3pjv1cqFfOMYvuWPb1iVPgCdCYqva
[28]        sr5KNWbge9r0tEh6Oogx0zAVrsdSYN30eSECch6NKlptD6L5KRKoorlCIBq7n2U70DpSWFYQHegJ
[29]        ier2yeY5hG6ceIZKKJ/fjDLH2NzWidoXk3NWqc3X836YCnoNyQ0oqgkz6gPSyWTpWnJ+j/WNBouA
[30]        ImEAiehOOgnNBJgS72z5iJsDFcLfI6cX/WmibSp3nR/AMQ==
[31]      </sl:X509Certificate>
[32]    </sl:RecipientPublicKey>
[33]    <sl:ToBeEncrypted>
[34]      <New ParentSelector="/" NodeCount="0">
[35]        <sl:MetaInfo>
[36]          <sl:MimeType>text/html</sl:MimeType>
[37]        </sl:MetaInfo>
[38]        <sl:Content>
[39]          <sl:XMLContent>
[40]            <html xmlns="http://www.w3.org/1999/xhtml">
[41]              <head>
[42]                <title>Ein einfaches SLXHTML-Dokument</title>
[43]                <style type="text/css">p { color: red; }</style>
[44]              </head>
[45]              <body>
[46]                <p>Ich bin ein einfacher Text in rot.</p>
[47]              </body>
[48]            </html>
[49]          </sl:XMLContent>
[50]        </sl:Content>
[51]      </sl:New>
[52]    </sl:ToBeEncrypted>
[53]  </sl:EncryptXMLRequest>

Line 2 contains the relevant command of the Security Layer interface.

Lines 3 to 5 contain the name space declarations for the XML elements that comprise the request.

Lines 6 to 32 contain the base64 encoded X509 certificate of the recipient.

Lines 35 to 37 contain meta information required by the viewer for displaying the data which should to be encrypted.

Lines 40 to 48 contain the XML document which should be encrypted.

Response

The provided XML document is encrypted according to the XMLENC standard:

[01]  <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
[02]  <sl:EncryptXMLResponse
[03]    xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]    <sl:EncryptionEnvironment>
[05]      <xenc:EncryptedData
[06]        xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
[07]	     Id="encrypted-data-0-1152523792-32960945-15207">
[08]        <xenc:EncryptionMethod
[09]          Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
[10]        <ds:KeyInfo
[11]          xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
[12]          <xenc:EncryptedKey
[13]            Id="encrypted-key-1-1152523792-32960975-11645-c0">
[14]            <xenc:EncryptionMethod
[15]              Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
[16]            <ds:KeyInfo>
[17]              <ds:KeyValue>
[18]                <ds:RSAKeyValue>
[19]                  <ds:Modulus>
[20]                    vOkAqNrQ4jaIYL65+nyExij9TWICMhj8dw6Ahv5Q37SovhGYYS3UJNgFybq3
[21]                    c0gaL36lVNq3ScqZKweqzk22Vkm9qEgeuzqr82+zq/MtNUeRHCX0JyCwXngx
[22]                    0rP8vMTjXJn4QTTsepbyXr04hc1JWsVLiQagQlQcUZZ2R7vUqlt+7j7Z3Zx9
[23]                    T2Mxf+tTMHP99xt6DYgxjcOEji4ftHj3Z5LlsSZtmdiVK68rgSbczHdMWsvx
[24]                    k6M04Kd8kC4Bt/2D
[25]                  </ds:Modulus>
[26]                  <ds:Exponent>
[27]                    AQAB<
[28]                  /ds:Exponent>
[29]                </ds:RSAKeyValue>
[30]              </ds:KeyValue>
[31]            </ds:KeyInfo>
[32]            <xenc:CipherData>
[33]              <xenc:CipherValue>
[34]                FsLNfU5wpNNTyRjmAxWVGAnH1Qfj2/3LfffD1D3kleCQQtg3JjmrKlCp8NDr
[35]                JT7vP2Ymb+TTrm9NUKkJzo7B1cDX0uB86GefY+j9aX/L7PB2x9hu0/1kpvxn
[36]                xtWaqe6PnoEVZr6Y0Af5bAPOEcMnvi/lnxqjz2EsiF5AuP4MktkXuIWuKzEk
[37]                oc/bKWDJUuLzVQN+JVKPfuZJwB1yjaoFguA+4dW+17mdS3OLmde4sIfJxaMD
[38]                aUN9thYDAZR3pnU9
[39]              </xenc:CipherValue>
[40]            </xenc:CipherData>
[41]          </xenc:EncryptedKey>
[42]        </ds:KeyInfo>
[43]        <xenc:CipherData>
[44]          <xenc:CipherValue>
[45]            l7VSOyeHIbF/1RgLNUD7is97aSA7VQT239/B2ZZ1CfAs6UHUwbNugP/4ymbL
[46]            HAwIjvo1eWXit/WdEi1PhkiGRGEDLz7vX0xgkc2SauZ1f5e4/irvhUjYm1nb
[47]            nk/JoV8gaItGVY/ZVjtdXTKy48oJk7hgltIRi5Mnf7XZIevt0e1Z3eVdcam9
[48]            k+z+kBahsSJIL6bwaK6N6dtk38nA+4/1iVvm676Np06Uq42Q/rHPXm0IVcQ3
[49]            11yirh3idgQUx60J0+J0tGAOzpfElUnDwk3pwr86kjg7eyzUjYGHT+IFidjv
[50]            H0WR4MvlXA==
[51]          </xenc:CipherValue>
[52]        </xenc:CipherData>
[53]      </xenc:EncryptedData>
[54]    </sl:EncryptionEnvironment>
[55]  </sl:EncryptXMLResponse

Line 2 contains the relevant response of the Security Layer interface.

Line 3 contains the name space declarations for the XML elements that comprise the request.

Lines 5 to 15 contain details about the encrypted document and the used algorithms.

Lines 12 to 41 contain the RSA encrypted session key, which is needed for the en/decryption of the data.

Lines 43 to 52 contain the XML document which is encrypted with the session key.

Downloads for this example
Further information

2.3.2.2 Encryption of an element within an existing XML document (Element)

Request

The following example shows how to encrypt a single element within an existing XML document. This element is selected by providing an XPATH expression in the attribute @selector of the element Element. Each namespace defined in the XML document must be known to the encryption request.

[01]  <?xml version="1.0" encoding="UTF-8"?>
[02]    <sl:EncryptXMLRequest
[03]      xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#"
[04]      xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
[05]      xmlns:docns="http://www.w3.org/1999/xhtml">
[06]      <sl:RecipientPublicKey>
[07]        <sl:X509Certificate>
[08]          MIIFBDCCA+ygAwIBAgIDASpYMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJBVDFIMEYGA1UE
[09]          Cgw/QS1UcnVzdCBHZXMuIGYuIFNpY2hlcmhlaXRzc3lzdGVtZSBpbSBlbGVrdHIuIERhdGVudmVy
[10]          a2VociBHbWJIMR4wHAYDVQQLDBVhLXNpZ24tUHJlbWl1bS1FbmMtMDIxHjAcBgNVBAMMFWEtc2ln
[11]          bi1QcmVtaXVtLUVuYy0wMjAeFw0wNTA0MjEwNjE0MzdaFw0wOTA0MjEwNjE0MzdaMFoxCzAJBgNV
[12]          BAYTAkFUMRQwEgYDVQQDDAtQZXRlciBUZXVmbDEOMAwGA1UEBAwFVGV1ZmwxDjAMBgNVBCoMBVBl
[13]          dGVyMRUwEwYDVQQFEww2NjcxOTI1NzA2MzQwgd8wDQYJKoZIhvcNAQEBBQADgc0AMIHJAoHBALzp
[14]          AKja0OI2iGC+ufp8hMYo/U1iAjIY/HcOgIb+UN+0qL4RmGEt1CTYBcm6t3NIGi9+pVTat0nKmSsH
[15]          qs5NtlZJvahIHrs6q/Nvs6vzLTVHkRwl9CcgsF54MdKz/LzE41yZ+EE07HqW8l69OIXNSVrFS4kG
[16]          oEJUHFGWdke71Kpbfu4+2d2cfU9jMX/rUzBz/fcbeg2IMY3DhI4uH7R492eS5bEmbZnYlSuvK4Em
[17]          3Mx3TFrL8ZOjNOCnfJAuAbf9gwIDAQABo4IB1zCCAdMwEwYDVR0jBAwwCoAIRyFHjpdh4x4wewYI
[18]          KwYBBQUHAQEEbzBtMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LmEtdHJ1c3QuYXQvY2VydHMvYS1z
[19]          aWduLVByZW1pdW0tRW5jLTAyYS5jcnQwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmEtdHJ1c3Qu
[20]          YXQvb2NzcDBNBgNVHSAERjBEMEIGBiooABEBDDA4MDYGCCsGAQUFBwIBFipodHRwOi8vd3d3LmEt
[21]          dHJ1c3QuYXQvZG9jcy9jcC9hLXNpZ24tdG9rZW4wgZoGA1UdHwSBkjCBjzCBjKCBiaCBhoaBg2xk
[22]          YXA6Ly9sZGFwLmEtdHJ1c3QuYXQvb3U9YS1zaWduLVByZW1pdW0tRW5jLTAyLG89QS1UcnVzdCxj
[23]          PUFUP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q/YmFzZT9vYmplY3RjbGFzcz1laWRDZXJ0aWZp
[24]          Y2F0aW9uQXV0aG9yaXR5MBEGA1UdDgQKBAhEc3YCuoW7uDAOBgNVHQ8BAf8EBAMCBLAwJQYDVR0R
[25]          BB4wHIEacGV0ZXIudGV1ZmxAaWFpay50dWdyYXouYXQwCQYDVR0TBAIwADANBgkqhkiG9w0BAQUF
[26]          AAOCAQEAJfg2cBaLMaXVqoZ23UA8qKxTxh+WeSlEveI4Ca43tu89uutJ3w/rXVFJ1EcSaA4OTAJt
[27]          icp5LstzJmrJoTcxbb3gC46x5MrgyvDbiTb/AiHBw11C0GN3pjv1cqFfOMYvuWPb1iVPgCdCYqva
[28]          sr5KNWbge9r0tEh6Oogx0zAVrsdSYN30eSECch6NKlptD6L5KRKoorlCIBq7n2U70DpSWFYQHegJ
[29]          ier2yeY5hG6ceIZKKJ/fjDLH2NzWidoXk3NWqc3X836YCnoNyQ0oqgkz6gPSyWTpWnJ+j/WNBouA
[30]          ImEAiehOOgnNBJgS72z5iJsDFcLfI6cX/WmibSp3nR/AMQ==
[31]        </sl:X509Certificate>
[32]      </sl:RecipientPublicKey>
[33]      <sl:ToBeEncrypted>
[34]        <sl:Element
[35]          Selector="/docns:html/docns:head/docns:title">
[36]        </sl:Element>
[37]      </sl:ToBeEncrypted>
[38]      <sl:EncryptionInfo>
[39]        <sl:EncryptionEnvironment>
[40]          <sl:XMLContent>
[41]            <html xmlns="http://www.w3.org/1999/xhtml">
[42]              <head>
[43]                <title>Ein einfaches SLXHTML-Dokument</title>
[44]                <style type="text/css">p { color: red; }</style>
[45]              </head>
[46]              <body>
[47]                <p>Ich bin ein einfacher Text in rot.</p>
[48]              </body>
[49]            </html>
[50]          </sl:XMLContent>
[51]        </sl:EncryptionEnvironment>
[52]      </sl:EncryptionInfo>
[53]    </sl:EncryptXMLRequest>

Line 2 contains the relevant command of the Citizen Card Environment interface.

Line 3 to 5 contain the name space declarations for the XML elements that comprise the request.

Line 5 defines the namespace which is used by the given XML dokument (lines 41 to 49). This namespace is needed for the XPATH expression in line 35.

Lines 6 to 32 contain the base64 encoded X509 certificate of the recipient.

Lines 34 to 36 specify that only the element title of the given XML document (lines 41 to 49) should be encrypted.

Lines 41 to 49 contain the XML document. Only the element title of this document should be encrypted.

Response
[01]  <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
[02]    <sl:EncryptXMLResponse 
[03]      xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]      <sl:EncryptionEnvironment>
[05]        <html
[06]          xmlns="http://www.w3.org/1999/xhtml">
[07]          <head>
[08]            <xenc:EncryptedData 
[09]              xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
[10]              Id="encrypted-data-0-1152534185-43290818-11809"
[11]              Type="http://www.w3.org/2001/04/xmlenc#Element">
[12]                <xenc:EncryptionMethod 
[13]                  Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
[14]                 <ds:KeyInfo 
[15]                    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
[16]                    <xenc:EncryptedKey 
[17]                      Id="encrypted-key-1-1152534185-43290838-5497-c0">
[18]                      <xenc:EncryptionMethod 
[19]                        Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
[20]                      <ds:KeyInfo>
[21]                        <ds:KeyValue>
[22]                          <ds:RSAKeyValue>
[23]                            <ds:Modulus>
[24]                              vOkAqNrQ4jaIYL65+nyExij9TWICMhj8dw6Ahv5Q37SovhGYYS3UJNgFybq3
[25]                              c0gaL36lVNq3ScqZKweqzk22Vkm9qEgeuzqr82+zq/MtNUeRHCX0JyCwXngx
[26]                              0rP8vMTjXJn4QTTsepbyXr04hc1JWsVLiQagQlQcUZZ2R7vUqlt+7j7Z3Zx9
[27]                              T2Mxf+tTMHP99xt6DYgxjcOEji4ftHj3Z5LlsSZtmdiVK68rgSbczHdMWsvx
[28]                              k6M04Kd8kC4Bt/2D
[29]                            </ds:Modulus>
[30]                            <ds:Exponent>
[31]                              AQAB
[32]                            </ds:Exponent>
[33]                          </ds:RSAKeyValue>
[34]                        </ds:KeyValue>
[35]                      </ds:KeyInfo>
[36]                    <xenc:CipherData>
[37]                  <xenc:CipherValue>
[38]                    Yqc8dmj2/NgF6He3nhD36NyxkJ5bndlrXsI1M54Fgqeq6B16F02odj/6YYyH
[39]                    ygpmeU6sY9adbnab9Iq3Sbsa/YT7W239F9BWaMd2f2lnVzkro22A2e6xu4sd
[40]                    xGuHbfHdCQeIc8qlDoJK5tQadA4lS8nM37jCG+/Gp8QCIC+UxbF0iz3th6xD
[41]                    +r+K8P+rqXTQcscegpFycOQ6Bjg11HMzslF7W+kx75jcCwKy6/CtRMAI+mRZ
[42]                    GrSrHh66rM11e1Fx
[43]                  </xenc:CipherValue>
[44]                </xenc:CipherData>
[45]              </xenc:EncryptedKey>
[46]            </ds:KeyInfo>
[47]            <xenc:CipherData>
[48]              <xenc:CipherValue>
[49]                k7glMunnGceKGGaG+Ru3+gj+5j7jtrdwb1Dy9ef01hNjTZh/03UhGBIHwGd7
[50]                sZZ+JPoUcBKdKv1/9mvX7i4obcJa3FO0LrGFrWyAMHyIPi2KBlA3Sh4kk/W8
[51]                IJdyiXYY
[52]              </xenc:CipherValue>
[53]            </xenc:CipherData>
[54]          </xenc:EncryptedData>
[55]          <style type="text/css">p { color: red; }</style>
[56]        </head>
[57]        <body>
[58]          <p>Ich bin ein einfacher Text in rot.</p>
[59]        </body>
[60]      </html>
[61]    </sl:EncryptionEnvironment>
[62]  </sl:EncryptXMLResponse>

Line 2 contains the relevant response of the Security Layer interface.

Line 3 contains the name space declarations for the XML elements that comprise the request.

Lines 5 to 60 contain the XML document given in the request. The element title is encrypted and included in lines 8 to 54.

Downloads for this example
Further information

2.3.2.3 Encryption of the element content of an XML document (ElementContent)

Request

The following example shows how to encrypt the content of a single element within an existing XML document. This element is selected by providing an XPATH expression in the attribute @selector of the element Element. Each namespace defined in the XML document must be known to the encryption request.

[01]  <?xml version="1.0" encoding="UTF-8"?>
[02]    <sl:EncryptXMLRequest
[03]      xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#"
[04]      xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
[05]      xmlns:docns="http://www.w3.org/1999/xhtml">
[06]      <sl:RecipientPublicKey>
[07]        <sl:X509Certificate>
[08]          MIIFBDCCA+ygAwIBAgIDASpYMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYDVQQGEwJBVDFIMEYGA1UE
[09]          Cgw/QS1UcnVzdCBHZXMuIGYuIFNpY2hlcmhlaXRzc3lzdGVtZSBpbSBlbGVrdHIuIERhdGVudmVy
[10]          a2VociBHbWJIMR4wHAYDVQQLDBVhLXNpZ24tUHJlbWl1bS1FbmMtMDIxHjAcBgNVBAMMFWEtc2ln
[11]          bi1QcmVtaXVtLUVuYy0wMjAeFw0wNTA0MjEwNjE0MzdaFw0wOTA0MjEwNjE0MzdaMFoxCzAJBgNV
[12]          BAYTAkFUMRQwEgYDVQQDDAtQZXRlciBUZXVmbDEOMAwGA1UEBAwFVGV1ZmwxDjAMBgNVBCoMBVBl
[13]          dGVyMRUwEwYDVQQFEww2NjcxOTI1NzA2MzQwgd8wDQYJKoZIhvcNAQEBBQADgc0AMIHJAoHBALzp
[14]          AKja0OI2iGC+ufp8hMYo/U1iAjIY/HcOgIb+UN+0qL4RmGEt1CTYBcm6t3NIGi9+pVTat0nKmSsH
[15]          qs5NtlZJvahIHrs6q/Nvs6vzLTVHkRwl9CcgsF54MdKz/LzE41yZ+EE07HqW8l69OIXNSVrFS4kG
[16]          oEJUHFGWdke71Kpbfu4+2d2cfU9jMX/rUzBz/fcbeg2IMY3DhI4uH7R492eS5bEmbZnYlSuvK4Em
[17]          3Mx3TFrL8ZOjNOCnfJAuAbf9gwIDAQABo4IB1zCCAdMwEwYDVR0jBAwwCoAIRyFHjpdh4x4wewYI
[18]          KwYBBQUHAQEEbzBtMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LmEtdHJ1c3QuYXQvY2VydHMvYS1z
[19]          aWduLVByZW1pdW0tRW5jLTAyYS5jcnQwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmEtdHJ1c3Qu
[20]          YXQvb2NzcDBNBgNVHSAERjBEMEIGBiooABEBDDA4MDYGCCsGAQUFBwIBFipodHRwOi8vd3d3LmEt
[21]          dHJ1c3QuYXQvZG9jcy9jcC9hLXNpZ24tdG9rZW4wgZoGA1UdHwSBkjCBjzCBjKCBiaCBhoaBg2xk
[22]          YXA6Ly9sZGFwLmEtdHJ1c3QuYXQvb3U9YS1zaWduLVByZW1pdW0tRW5jLTAyLG89QS1UcnVzdCxj
[23]          PUFUP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q/YmFzZT9vYmplY3RjbGFzcz1laWRDZXJ0aWZp
[24]          Y2F0aW9uQXV0aG9yaXR5MBEGA1UdDgQKBAhEc3YCuoW7uDAOBgNVHQ8BAf8EBAMCBLAwJQYDVR0R
[25]          BB4wHIEacGV0ZXIudGV1ZmxAaWFpay50dWdyYXouYXQwCQYDVR0TBAIwADANBgkqhkiG9w0BAQUF
[26]          AAOCAQEAJfg2cBaLMaXVqoZ23UA8qKxTxh+WeSlEveI4Ca43tu89uutJ3w/rXVFJ1EcSaA4OTAJt
[27]          icp5LstzJmrJoTcxbb3gC46x5MrgyvDbiTb/AiHBw11C0GN3pjv1cqFfOMYvuWPb1iVPgCdCYqva
[28]          sr5KNWbge9r0tEh6Oogx0zAVrsdSYN30eSECch6NKlptD6L5KRKoorlCIBq7n2U70DpSWFYQHegJ
[29]          ier2yeY5hG6ceIZKKJ/fjDLH2NzWidoXk3NWqc3X836YCnoNyQ0oqgkz6gPSyWTpWnJ+j/WNBouA
[30]          ImEAiehOOgnNBJgS72z5iJsDFcLfI6cX/WmibSp3nR/AMQ==
[31]        </sl:X509Certificate>
[32]      </sl:RecipientPublicKey>
[33]      <sl:ToBeEncrypted>
[34]        <sl:ElementContent
[35]          Selector="/docns:html/docns:head/docns:title">
[36]        </sl:ElementContent>
[37]      </sl:ToBeEncrypted>
[38]      <sl:EncryptionInfo>
[39]        <sl:EncryptionEnvironment>
[40]          <sl:XMLContent>
[41]            <html xmlns="http://www.w3.org/1999/xhtml">
[42]              <head>
[43]                <title>Ein einfaches SLXHTML-Dokument</title>
[44]                <style type="text/css">p { color: red; }</style>
[45]              </head>
[46]              <body>
[47]                <p>Ich bin ein einfacher Text in rot.</p>
[48]              </body>
[49]            </html>
[50]          </sl:XMLContent>
[51]        </sl:EncryptionEnvironment>
[52]      </sl:EncryptionInfo>
[53]    </sl:EncryptXMLRequest>

Line 2 contains the relevant command of the Security Layer interface.

Line 3 to 5 contain the name space declarations for the XML elements that comprise the request.

Line 5 defines the namespace which is used by the given XML document (lines 41 to 49). This namespace is needed for the XPATH expression in line 35.

Lines 6 to 32 contain the base64 encoded X509 certificate of the recipient.

Lines 34 to 36 specify that only the content of the element title of the given XML document (lines 41 to 49) should be encrypted.

Lines 41 to 49 contain the XML document. Only the content of the element title of this document should be encrypted.

Antwort
[01]  <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
[02]    <sl:EncryptXMLResponse 
[03]      xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]      <sl:EncryptionEnvironment>
[05]        <html
[06]          xmlns="http://www.w3.org/1999/xhtml">
[07]          <head>
[08]            <title>
[09]              <xenc:EncryptedData
[10]                xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
[11]                Id="encrypted-data-0-1152532362-41467517-23174" 
[12]                Type="http://www.w3.org/2001/04/xmlenc#Content">
[13]                <xenc:EncryptionMethod
[14]                  Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
[15]                <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
[16]                  <xenc:EncryptedKey
[17]                    Id="encrypted-key-1-1152532362-41467527-29158-c0">
[18]                    <xenc:EncryptionMethod
[19]                      Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
[20]                    <ds:KeyInfo>
[21]                      <ds:KeyValue>
[22]                        <ds:RSAKeyValue>
[23]                          <ds:Modulus>
[24]                            vOkAqNrQ4jaIYL65+nyExij9TWICMhj8dw6Ahv5Q37SovhGYYS3UJNgFybq3
[25]                            c0gaL36lVNq3ScqZKweqzk22Vkm9qEgeuzqr82+zq/MtNUeRHCX0JyCwXngx
[26]                            0rP8vMTjXJn4QTTsepbyXr04hc1JWsVLiQagQlQcUZZ2R7vUqlt+7j7Z3Zx9
[27]                            T2Mxf+tTMHP99xt6DYgxjcOEji4ftHj3Z5LlsSZtmdiVK68rgSbczHdMWsvx
[28]                            k6M04Kd8kC4Bt/2D
[29]                          </ds:Modulus>
[30]                          <ds:Exponent>
[31]                            AQAB
[32]                          </ds:Exponent>
[33]                        </ds:RSAKeyValue>
[34]                      </ds:KeyValue>
[35]                    </ds:KeyInfo>
[36]                    <xenc:CipherData>
[37]                      <xenc:CipherValue>
[38]                        MDA77eIm+HXZnVkMAl3Ox858BAG7fSeLGTIcmtm/dKjp8Sk2M12RN7xqvIoP
[39]                        LsYab8ddAJktE/s+Tk1MKzGPdlvfHZInu4OVjKQfHOReuic8ndmjc8K2kBot
[40]                        uNz0WTKAEOQ1l2zgNBVKnbeFzI2ozrO1uHBfeR2t+pu92mp1L8FvATW/+tD/
[41]                        7AAwRROxZut2jFrmmw/ajfUWMtNm+8gtpwqdx12N03tbW9tihKlYKgKspOL6
[42]                        GGPYBysIjl39KbTq
[43]                      </xenc:CipherValue>
[44]                    </xenc:CipherData>
[45]                  </xenc:EncryptedKey>
[46]                </ds:KeyInfo>
[47]                <xenc:CipherData>
[48]                  <xenc:CipherValue>
[49]                    NhUqASe+jJ0BHqTX4sayQLz7qUNbO8Wdj9qEI4wm+9Mbml3Agfjluw==
[50]                  </xenc:CipherValue>
[51]                </xenc:CipherData>
[52]              </xenc:EncryptedData>
[53]            </title>
[54]            <style type="text/css">p { color: red; }</style>
[55]          </head>
[56]          <body>
[57]            <p>Ich bin ein einfacher Text in rot.</p>
[58]          </body>
[59]        </html>
[60]      </sl:EncryptionEnvironment>
[61]    </sl:EncryptXMLResponse>

Line 2 contains the relevant response of the Security Layer interface.

Line 3 contains the name space declarations for the XML elements that comprise the request.

Lines 5 to 60 contain the XML document given in the request. The content of the element title is encrypted and included in lines 9 to 52.

Downloads for this example
Further Information

 

2.4 Data decryption

2.4.1 Data decryption using the CMS standard

Request

The DecryptCMSRequest is used to decrypt data which is encrypted according to the CMS standard. The base64 encoded CMS message is given in the element sl:CMSMessage. Alternatively the data which should be decrypted, can be given by specifying a reference in the attribute sl:Content/@Reference.

Additionally, meta information is stored in the element sl:EncryptedContent. The element sl:EncryptedContent/sl:MetaInfo/sl:MimeType specifies the mime type of the data. This information is used by the viewer of the Citizen Card Environment for displaying the data. The element sl:ToBeEncrypted/sl:MetaInfo/sl:Description is not mandatory and can be used to describe the data verbally.

[01]  <?xml version="1.0" encoding="UTF-8"?>
[02]    <sl:DecryptCMSRequest 
[03]	  xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]      <sl:CMSMessage>
[05]        MIIB3AYJKoZIhvcNAQcDoIIBzTCCAckCAQExggF7MIIBdwIBATCBnzCBlzEL
[06]        MAkGA1UEBhMCQVQxSDBGBgNVBAoMP0EtVHJ1c3QgR2VzLiBmLiBTaWNoZXJo
[07]        ZWl0c3N5c3RlbWUgaW0gZWxla3RyLiBEYXRlbnZlcmtlaHIgR21iSDEeMBwG
[08]        A1UECwwVYS1zaWduLVByZW1pdW0tRW5jLTAyMR4wHAYDVQQDDBVhLXNpZ24t
[09]        UHJlbWl1bS1FbmMtMDICAwEqWDANBgkqhkiG9w0BAQEFAASBwBiwSIHzq6LK
[10]        4RcT6wrA6TuJAHgsVRtirQQhMkvgSWyozC5SJoyYDVuqFgci+0MwBioPp7H6
[11]        gv0m2RAp3p7MdyaUBY7WzC9X5anTcioCuI1E4EoQJGyg+rUD7PzrRl/HroP3
[12]        EEzGK7jZCJ9ToWmleMMYsLmtkMJ5MlnRdtyuReLU8ATfGCJOMSJlUDuiVqmU
[13]        UOSO/l8M6AyXz7ZJ7ntgf6IJtOo0G/f5Ph/smWWXltKD2nWxzJUUaXs75lfB
[14]        +/KfTjBFBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECPEnrwVJxQ54oCIEIBcB
[15]        bbIEsKpuWsUxFFPBBjTJtV8rVFXfpTBFuC03ltTo
[16]      </sl:CMSMessage>
[17]      <sl:EncryptedContent>
[18]        <sl:MetaInfo>
[19]          <sl:MimeType>text/plain</sl:MimeType>
[20]        </sl:MetaInfo>
[21]        <sl:Description>
[22]           Diese Daten liegen als reiner Text vor.
[23]        </sl:Description>
[24]      </sl:EncryptedContent>
[25]    </sl:DecryptCMSRequest>

Line 2 contains the relevant command of the Security Layer interface.

Line 3 contains the name space declarations for the XML elements that comprise the request.

Lines 4 to 16 contain the base64 encoded CMS message, which shoould be decrypted.

Lines 17 to 24 contain meta information which is needed for displaying the data.


Response
The response contains the base64 encoded decrypted data in the element sl:DecryptedData.
[01]  <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
[02]  <sl:DecryptCMSResponse 
[03]    xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]    <sl:DecryptedData>
[05]      SWNoIGJpbiBlaW4gZWluZmFjaGVyIFRleHQu
[06]    </sl:DecryptedData>
[05]  </sl:DecryptCMSResponse>
Downloads for this example
Further information

2.4.2 Data decryption using the XMLENC standard

Request

Data which is encrypted according to the XMLENC standard, is decrypted by using the DecryptXMLRequest. If the encrypted data is base64 encoded, it is given in the element sl:EncryptedContent/sl:Base64Content. Data which is encrypted according to the XMLENC standard is given in the element sl:EncryptedContent/sl:XMLContent. Furthermore, if the encrypted data is available at a reference, this reference can be given in the attribute sl:EncryptedContent/sl:Content/@Reference.

The element sl:EncrElemeSelector is used to specify which encrypted elements should be decrypted. The expression in this element must be in accordance to the XPATH standard.

[01]  <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
[02]    <sl:DecryptXMLRequest
[03]      xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]      <sl:EncryptedContent>
[05]        <sl:XMLContent>
[06]          <xenc:EncryptedData 
[07]  		  xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
[08]  		  Id="encrypted-data-0-1152184915-1418099-32011">
[09]            <xenc:EncryptionMethod 
[10]  		    Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
[11]            <ds:KeyInfo 
[12]  		    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
[13]            <xenc:EncryptedKey 
[14]  		    Id="encrypted-key-1-1152184915-1418139-8806-c0">
[15]              <xenc:EncryptionMethod 
[16]  		      Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
[17]                <ds:KeyInfo>
[18]  		        <ds:KeyValue>
[19]                    <ds:RSAKeyValue>
[20]                      <ds:Modulus>
[21]                        vOkAqNrQ4jaIYL65+nyExij9TWICMhj8dw6Ahv5Q37SovhGYYS3UJNgFybq3
[22]                        c0gaL36lVNq3ScqZKweqzk22Vkm9qEgeuzqr82+zq/MtNUeRHCX0JyCwXngx
[23]                        0rP8vMTjXJn4QTTsepbyXr04hc1JWsVLiQagQlQcUZZ2R7vUqlt+7j7Z3Zx9
[24]                        T2Mxf+tTMHP99xt6DYgxjcOEji4ftHj3Z5LlsSZtmdiVK68rgSbczHdMWsvx
[25]                        k6M04Kd8kC4Bt/2D
[26]                      </ds:Modulus>
[27]                      <ds:Exponent>AQAB</ds:Exponent>
[28]                    </ds:RSAKeyValue>
[29]                  </ds:KeyValue>
[30]                </ds:KeyInfo>
[31]                <xenc:CipherData>
[32]                  <xenc:CipherValue>
[33]                    HTwgNQCRkfvU7dqlV/83mfkTevsFn8HTek54nQD+Erno/4IWWTn83riXF5i+
[34]                    u1y53bqiwXDduOmMzPsQj/8q2EuqsWzvEQm+aKItVXyX1AqXt11NEVCoR62Q
[35]                    qV+WcH61GM35swC92Ohe0S8hXLsaQUCgQHq7klzBjkXeLRFLCchZjsgc3Miy
[36]                    lIZdsNcZvZYsMZK0kpLiscH/WRrklSZdTT3tJwQqilSyHAFOz9AOCFai5p3b
[37]                    gsWdblZWm65w8vJe
[38]                  </xenc:CipherValue>
[39]                </xenc:CipherData>
[40]              </xenc:EncryptedKey>
[41]            </ds:KeyInfo>
[42]            <xenc:CipherData>
[43]              <xenc:CipherValue>
[44]                BU4x6VaAFS4g9SJwDhoFK7MfRnr7CqAEqOnh1j0FuN/fJA4p8OJWtw==
[45]              </xenc:CipherValue>
[46]            </xenc:CipherData>
[47]         </xenc:EncryptedData>
[48]        </sl:XMLContent>
[49]      </sl:EncryptedContent>
[50]    <sl:EncrElemsSelector>
[51]      //*[@Id='encrypted-data-0-1151396325-49021018-4645']
[52]    </sl:EncrElemsSelector>
[53]  </sl:DecryptXMLRequest>

Line 2 contains the relevant command of the Security Layer interface.

Line 3 contains the name space declarations for the XML elements that comprise the request.

Lines 6 to 47 contain the encrypted data (according to the XMLENC standard).

Lines 50 bis 52 use an XPATH expression in the element EncrElemsSelector to select the data which should be decrypted.

Response
[01]  <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
[02]    <sl:DecryptXMLResponse 
[03]      xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]      <sl:CandidateDocument>
[05]        <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
[06]          Id="encrypted-data-0-1152184915-1418099-32011">
[07]          <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
[08]            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
[09]              <xenc:EncryptedKey Id="encrypted-key-1-1152184915-1418139-8806-c0">
[10]                <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
[11]                  <ds:KeyInfo>
[12]                    <ds:KeyValue>
[13]                      <ds:RSAKeyValue>
[14]                        <ds:Modulus>
[15]                          vOkAqNrQ4jaIYL65+nyExij9TWICMhj8dw6Ahv5Q37SovhGYYS3UJNgFybq3
[16]                          c0gaL36lVNq3ScqZKweqzk22Vkm9qEgeuzqr82+zq/MtNUeRHCX0JyCwXngx
[17]                          0rP8vMTjXJn4QTTsepbyXr04hc1JWsVLiQagQlQcUZZ2R7vUqlt+7j7Z3Zx9
[18]                          T2Mxf+tTMHP99xt6DYgxjcOEji4ftHj3Z5LlsSZtmdiVK68rgSbczHdMWsvx
[19]                          k6M04Kd8kC4Bt/2D
[20]                        </ds:Modulus>
[21]                        <ds:Exponent>
[22]                          AQAB 
[23]                        </ds:Exponent>
[24]                      </ds:RSAKeyValue>
[25]                    </ds:KeyValue>
[26]                  </ds:KeyInfo>
[27]                  <xenc:CipherData>
[28]                    <xenc:CipherValue>
[29]                      HTwgNQCRkfvU7dqlV/83mfkTevsFn8HTek54nQD+Erno/4IWWTn83riXF5i+
[30]                      u1y53bqiwXDduOmMzPsQj/8q2EuqsWzvEQm+aKItVXyX1AqXt11NEVCoR62Q
[31]                      qV+WcH61GM35swC92Ohe0S8hXLsaQUCgQHq7klzBjkXeLRFLCchZjsgc3Miy
[32]                      lIZdsNcZvZYsMZK0kpLiscH/WRrklSZdTT3tJwQqilSyHAFOz9AOCFai5p3b
[33]                      gsWdblZWm65w8vJe
[34]                    </xenc:CipherValue>
[35]                  </xenc:CipherData>
[36]                </xenc:EncryptedKey>
[37]              </ds:KeyInfo>
[38]              <xenc:CipherData>
[39]                <xenc:CipherValue>
[40]                  BU4x6VaAFS4g9SJwDhoFK7MfRnr7CqAEqOnh1j0FuN/fJA4p8OJWtw==
[41]                </xenc:CipherValue>
[42]              </xenc:CipherData>
[43]            </xenc:EncryptedData>
[44]          </sl:CandidateDocument>
[45]        <sl:DecryptedBinaryData 
[46]          EncrElemSelector="//*[@Id='encrypted-data-0-1152184915-1418099-32011']">
[47]  	      SWNoIGJpbiBlaW4gZWluZmFjaGVyIFRleHQu 
[48]        </sl:DecryptedBinaryData>
[49]      </sl:DecryptXMLResponse>

Line 2 contains the relevant response of the Security Layer interface.

Line 3 contains the name space declarations for the XML elements that comprise the request.

Lines 6 to 44 contain the encrypted document given in the request.

Lines 45 to 48 contain the decrypted data, which is base64 encoded.

Downloads for this example
Further information

2.5 Calculating the hash value

2.5.1 Initial example

This example shows how to create hash values for any data. A request can be used to obtain hash values for several items of data at once. Similarly to commands described earlier, the data for which a hash value is to be calculated can be specified either explicitly in the request or using a reference with URL.

Request

The following request is used by the Citizen Card Environment to request the calculation of two hash values.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:CreateHashRequest xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[03]   <sl:HashInfo RespondHashData="true">
[04]     <sl:HashData>
[05]       <sl:MetaInfo>
[06]         <sl:MimeType>text/plain</sl:MimeType>
[07]       </sl:MetaInfo>
[08]       <sl:Content>
[09]         <sl:XMLContent>Hasch' mich, ich bin der Frühling!</sl:XMLContent>
[10]       </sl:Content>
[11]     </sl:HashData>
[12]     <sl:HashAlgorithm>http://www.w3.org/2000/09/xmldsig#sha1</sl:HashAlgorithm>
[13]     <sl:FriendlyName>Aktueller Stimmungsbericht :-)</sl:FriendlyName>
[14]   </sl:HashInfo>

Lines 3 to 14 contain all the information for calculating the first hash value.

The sl:RespondHashData attribute in line 3 defines whether the data for which the hash value is to be calculated is to be returned in the response. In this case, the value is true, i.e. the XML structure of lines 4 to 11 will appear identically in the response.

Lines 4 to 11 contain the details of the data for which the hash value is to be calculated. The meta information for this data – as in line 6 above – must always include the mime type. The mime type allows the Citizen Card Environment to select the right viewer component when the citizen wants to view the data to be hashed. The data to be hashed itself must also be specified with the sl:Content element. The specification can take the explicit form of a set of XML nodes – as in lines 9 to 11 here, a simple text node – in the sl:XMLContent element or can appear in base64-encoded form in the sl:Base64Content element or can be made using a URL reference with the sl:Content/@Reference attribute (compare further below).

The sl:HashAlgorithm element in line 12 defines the hash algorithm to be used by the Citizen Card Environment. The value used here identifies SHA-1.

As an option, the sl:FriendlyName element can be specified. The freely selectable text contained there is used by the Citizen Card Environment to make it easier for the citizen subsequently to recognise a hash value calculated during the course of a Citizen Card Environment session. It is therefore urgently recommended that this element be used and a meaningful text be chosen as a value.

[15]   <sl:HashInfo RespondHashData="false">
[16]     <sl:HashData>
[17]       <sl:MetaInfo>
[18]         <sl:MimeType>image/png</sl:MimeType>
[19]       </sl:MetaInfo>
[20]       <sl:Content Reference="http://www.buergerkarte.at/konzept/securitylayer/\
[21]         spezifikation/20040514/tutorial/examples/interface/common/ModellBuergerkarte.png"/>
[22]     </sl:HashData>
[23]     <sl:HashAlgorithm>http://www.w3.org/2000/09/xmldsig#sha1</sl:HashAlgorithm>
[24]     <sl:FriendlyName>Grafik Modell Bürgerkarte</sl:FriendlyName>
[25]   </sl:HashInfo>
[26] </sl:CreateHashRequest>

Lines 15 to 25 contain all the information for calculating the second hash value.

In this case, the hash value is to be calculated for an image in PNG format. The mime type is set accordingly in line 18. Unlike the first part of the example, the image data is not referenced directly, but rather using the sl:Content/@Reference attribute (lines 20 and 21). The Citizen Card Environment will resolve this reference to obtain the data to be hashed.

The value of the sl:RespondHashData attribute in line 15 is set to false, i.e. the XML structure of lines 16 to 22 is not mirrored in the response.

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted for better readability.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:CreateHashResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:HashInfo>
[05]     <sl:HashData>
[06]       <sl:MetaInfo>
[07]         <sl:MimeType>text/plain</sl:MimeType>
[08]       </sl:MetaInfo>
[09]       <sl:Content>
[10]         <sl:XMLContent>Hasch' mich, ich bin der Frühling!</sl:XMLContent>
[11]       </sl:Content>
[12]     </sl:HashData>
[13]     <sl:HashAlgorithm>http://www.w3.org/2000/09/xmldsig#sha1</sl:HashAlgorithm>
[14]     <sl:FriendlyName>Aktueller Stimmungsbericht :-)</sl:FriendlyName>
[15]     <sl:HashValue>+pWF1F0/8NpbRqBkRpREjK4p7LE=</sl:HashValue>
[16]   </sl:HashInfo>

The request pertains to the calculation of two hash values. Accordingly, the response contains two sl:HashInfo elements, one per calculated hash value. The order of the sl:HashInfo elements is the same as that of the sl:HashInfo elements in the request.

Lines 4 to 16 contain the information about the first hash value calculated. Since the RespondHashData attribute has been set to true in line 3 of the request, sl:HashInfo contains the sl:HashData element as the first child, precisely in the form in which it was specified in the request. The sl:HashAlgorithm element in line 13 and, if applicable, sl:FriendlyName in line 14 are also copied from the request in identical form.

The sl:HashValue element in line 15 contains the hash value calculated by the Citizen Card Environment of the data to be hashed. (Note: Since the data to be hashed has been specified as an XML structure in sl:XMLContent in this example, the Citizen Card Environment canonised the XML structure to obtain a unique representation as a sequence of bytes.)

[17]   <sl:HashInfo>
[18]     <sl:HashAlgorithm>http://www.w3.org/2000/09/xmldsig#sha1</sl:HashAlgorithm>
[19]     <sl:FriendlyName>Grafik Modell Bürgerkarte</sl:FriendlyName>
[10]     <sl:HashValue>BLMp3QLSXqO7qEO7N4pEnpzkqPo=</sl:HashValue>
[21]   </sl:HashInfo>
[22] </sl:CreateHashResponse>

Lines 17 to 21 contain the information about the second hash value calculated. Since the RespondHashData attribute has been set to false in line 15 of the request, the sl:HashData element is missing as a child of sl:HashInfo.

Downloads for this example

Further information

2.6 Verifying the hash value

2.6.1 Initial example

This example demonstrates how to verify hash values for any data. A request can be used to verify hash values for several data items at once. As with the commands described earlier, the data for which a hash value is to be recalculated can be specified either explicitly in the request or by means of a reference with URL.

Request

The following request is used by the Citizen Card Environment to request the verification of the hash values calculated in example 2.5.1.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:VerifyHashRequest xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[03]   <sl:HashInfo>
[04]     <sl:HashData>
[05]       <sl:MetaInfo>
[06]         <sl:MimeType>text/plain</sl:MimeType>
[07]       </sl:MetaInfo>
[08]       <sl:Content>
[09]         <sl:XMLContent>Hasch' mich, ich bin der Frühling!</sl:XMLContent>
[10]       </sl:Content>
[11]     </sl:HashData>
[12]     <sl:HashAlgorithm>http://www.w3.org/2000/09/xmldsig#sha1</sl:HashAlgorithm>
[13]     <sl:FriendlyName>Aktueller Stimmungsbericht :-)</sl:FriendlyName>
[14]     <sl:HashValue>+pWF1F0/8NpbRqBkRpREjK4p7LE=</sl:HashValue>
[15]   </sl:HashInfo>

Lines 3 to 15 contain all the information for verifying the first hash value.

Lines 4 to 11 contain the details of the data for which the hash value is to be recalculated. The meta information for this data – as in line 6 above – must include the mime type. The mime type allows the Citizen Card Environment to select the right viewer component when the citizen wants to view the data for which the hash value is to be recalculated. The data itself must also be specified with the sl:Content element. The specification can take the explicit form of a set of XML nodes – as in lines 9 to 11 here, a simple text node – in the sl:XMLContent element or can appear in base64-encoded form in the sl:Base64Content element or can be made using a URL reference with the sl:Content/@Reference attribute (compare further below).

The sl:HashAlgorithm element in line 12 defines the hash algorithm to be used by the Citizen Card Environment. The value used here identifies SHA-1.

As an option, the sl:FriendlyName element can be specified. The freely selectable text contained there is used by the Citizen Card Environment to make it easier for the citizen subsequently to recognise a hash value verified during the course of a Citizen Card Environment session. It is therefore urgently recommended that this element be used and a meaningful text be chosen as a value.

The sl:HashValue element in line 14 contains the reference hash value to be verified by the Citizen Card Environment.

[16]   <sl:HashInfo>
[17]     <sl:HashData>
[18]       <sl:MetaInfo>
[19]         <sl:MimeType>image/png</sl:MimeType>
[20]       </sl:MetaInfo>
[21]       <sl:Content Reference="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/\
[22]         20040514/tutorial/examples/interface/common/ModellBuergerkarte.png"/>
[23]     </sl:HashData>
[24]     <sl:HashAlgorithm>http://www.w3.org/2000/09/xmldsig#sha1</sl:HashAlgorithm>
[25]     <sl:FriendlyName>Grafik Modell Bürgerkarte</sl:FriendlyName>
[26]     <sl:HashValue>BLMp3QLSXqO7qEO7N4pEnpzkqPo=</sl:HashValue>
[27]   </sl:HashInfo>
[28] </sl:VerifyHashRequest>

Lines 15 to 25 contain all the information for verifying the second hash value.

In this case, the hash value for an image in PNG format is to recalculated. The mime type is set accordingly in line 19. Unlike in the first part of the example, the image data is not referenced directly, but rather using the sl:Content/@Reference attribute (lines 21 and 22). The Citizen Card Environment will resolve this reference to retrieve the image data.

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted for better readability.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:VerifyHashResponse xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[03]   <sl:VerificationResult>
[04]     <sl:FriendlyName>Aktueller Stimmungsbericht :-)</sl:FriendlyName>
[05]     <sl:Result>1</sl:Result>
[06]   </sl:VerificationResult>
[07]   <sl:VerificationResult>
[08]     <sl:FriendlyName>Grafik Modell Bürgerkarte</sl:FriendlyName>
[09]     <sl:Result>1</sl:Result>
[10]   </sl:VerificationResult>
[11] </sl:VerifyHashResponse>

The response contains for each hash value submitted in the request for verification a corresponding sl:VerificationResult element; there are two such elements in this particular case. The sequence is the same as that of the sl:HashInfo elements in the request.

As an option, sl:VerificationResult first contains the sl:FriendlyName element whenever this element was also contained in the corresponding sl:HashInfo of the request. sl:Result contains the result of the verification of the hash value. If it was possible to verify the value successfully, it contains the value true (or 1 which means the same), otherwise the value is false (or 0).

Downloads for this example

Further information

2.7 Info boxes

2.7.1 Reading out available info boxes

This example demonstrates how to read out the identifiers for all info boxes available in the Citizen Card Environment. These identifiers can then be used in the commands to read, change and delete info boxes.

Request

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxAvailableRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#"/>

The request consists of the empty sl:InfoboxAvailableRequest element.

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted for better readability.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxAvailableResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:InfoboxIdentifier>Certificates</sl:InfoboxIdentifier>
[05]   <sl:InfoboxIdentifier>IdentityLink</sl:InfoboxIdentifier>
[06]   <sl:InfoboxIdentifier>CompressedIdentityLink</sl:InfoboxIdentifier>
[07]   <sl:InfoboxIdentifier>Mandates</sl:InfoboxIdentifier>
[08] </sl:InfoboxAvailableResponse>

For each available info box, the response contains an sl:InfoboxIdentifier element with the identifier of the info box (cf. lines 4 to 7).

Downloads for this example

Further information

2.7.2 Creating an info box

2.7.2.1 Initial example

This example shows the minimum command required to create a new info box within the Citizen Card Environment. This creates a new info box which is empty to begin with. The access rights are defined solely by means of the user interface.

Request
[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxCreateRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:InfoboxIdentifier>TutorialBinary</sl:InfoboxIdentifier>
[05]   <sl:InfoboxType>BinaryFile</sl:InfoboxType>
[06]   <sl:Creator>Tutorium zur österreichischen Bürgerkarte</sl:Creator>
[07]   <sl:Purpose>Demonstriert das Anlegen, Lesen, Verändern und Löschen einer\
[08]     Binärdatei.</sl:Purpose>
[09] </sl:InfoboxCreateRequest>

As the content of the sl:InfoboxIdentifier element, the request first contains the freely selectable identifier for the new info box to be created in line 4, in this example TutorialBinary.

The type of info box is specified in line 5; possible values are BinaryFile for a binary file or AssocArray for an associative array. A binary file is to be created in this example.

sl:Creator in line 6 contains a free text describing the application that wants to create the info box. This information is supplied to the citizen by the Citizen Card Environment using the user interface.

Finally, sl:Purpose contains a free text describing the purpose of the info box in line 7. This information is also supplied to the citizen by the Citizen Card Environment via the user interface.

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted for better readability.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxCreateResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#"/>

The response consists of the empty sl:InfoboxCreateResponse element.

Downloads for this example
Further information

2.7.2.2 Extended example

This example shows how to create an associative-array type info box within the Citizen Card Environment; suggestions or requirements in relation to the access rights and notification policy are already made by the Citizen Card Environment in the request.

Request
[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxCreateRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:InfoboxIdentifier>TutorialAssocArray</sl:InfoboxIdentifier>
[05]   <sl:InfoboxType>AssocArray</sl:InfoboxType>
[06]   <sl:Creator>Tutorium zur österreichischen Bürgerkarte</sl:Creator>
[07]   <sl:Purpose>Demonstriert das Anlegen, Lesen, Verändern und Löschen\
[08]     eines assoziativen Arrays.</sl:Purpose>

The first four child elements have already been described in the first example of how to create an info box.

[09]   <sl:ReadAccessAuthorization UserMayChange="true">
[10]     <sl:RequesterID AuthenticationClass="anonym">*</sl:RequesterID>
[11]   </sl:ReadAccessAuthorization>
[12]   <sl:UpdateAccessAuthorization UserMayChange="false">
[13]     <sl:RequesterID 
[14]       AuthenticationClass="certified">meine.applikation.at</sl:RequesterID>
[15]   </sl:UpdateAccessAuthorization>
[16]   <sl:ReadUserConfirmation 
[17]     UserMayChange="true">confirm</sl:ReadUserConfirmation>
[18]   <sl:UpdateUserConfirmation 
[19]     UserMayChange="true">confirmWithSecret</sl:UpdateUserConfirmation>
[20] </sl:InfoboxCreateRequest>

The remaining four child elements contain proposals and requirements for the Citizen Card Environment concerning the access rights to the info box and the notification policy of the Citizen Card Environment in relation to the citizen when accessing the info box.

sl:ReadAccessAuthorization in lines 9 to 11 suggests which applications are permitted read access to the info box. This is (only) a suggestion because when the UserMayChange attribute is set to true, the Citizen Card Environment knows that the citizen may change this suggestion at his own discretion.

sl:ReadAccessAuthorization must contain at least one sl:RequestID element. Each of these elements indicates which application may access the info box. The element's text content specifies either an IP address or a domain name; the * wildcard can be used from the right for one or more subnets of an IP address (e.g. 127.*) or from the left for one or more subdomains of a domain name (*.ac.at). The value of the AuthenticationClass attribute indicates the minimum class for the authentication of the application by the Citizen Card Environment so that the rule expressed by sl:RequestID works. If more than one sl:RequestID element is specified, the rules are processed by the Citizen Card Environment in succession. The first rule that applies to the specific request is used to decide whether access is permitted. In this specific case, the rule stipulates that any application (*) is permitted read access to the info box; the application does not need to be authenticated by the Citizen Card Environment (class anonym).

sl:UpdateAccessAuthorization in lines 12 to 15 indicates which applications are permitted to access the info box to make changes. This is a requirement because when the UserMayChange attribute is set to false, the Citizen Card Environment knows that the citizen must not change this requirement (Note: He may, however, refuse to create the info box as a whole). As above, sl:UpdateAccessAuthorization contains at least one sl:RequestID element. In this particular case, the only existing rule stipulates that solely the meine.applikation.at application may access the info box to make changes; it is necessary for the application to be authenticated by the Citizen Card Environment in accordance with the class certified.

In lines 16 and 17, sl:ReadUserConfirmation suggests how the Citizen Card Environment should inform the citizen of a read access that is permitted according to the rules defined for the info box. confirm means that the citizen must confirm permission for execution via the user interface.

In lines 18 and 19, sl:UpdateUserConfirmation suggests how the Citizen Card Environment should inform the citizen of a change access that is permitted according to the rules defined for the info box. confirmWithSecret means that the citizen must confirm the execution permission via the user interface by entering a password.

Response

Here again the response consists of the empty sl:InfoboxCreateResponse element and is not shown again at this point.

Downloads for this example
Further information

2.7.3 Deleting an info box

This command shows how to delete an info box. This command does not work with standardised info boxes.

Request

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxDeleteRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:InfoboxIdentifier>TutorialBinary</sl:InfoboxIdentifier>
[05] </sl:InfoboxDeleteRequest>

The child element sl:InfoboxIdentifier contains the identifier for the info box to be deleted, in this case TutorialBinary.

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted for better readability.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxDeleteResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#"/>

The request consists of the empty sl:InfoboxDeleteResponse element.

Downloads for this example

Further information

2.7.4 Reading an info box

2.7.4.1 Reading a binary file

The following examples demonstrate how to read a binary-file type info box. A binary file is read out in its entirety.

2.7.4.1.1 Initial example

The following example demonstrates the simple reading of a binary-file type info box. If you want to try this example for yourself, first execute example 2.7.2.1 (creating an info box) and example 2.7.5.1 (changing a binary file).

Request
[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxReadRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:InfoboxIdentifier>TutorialBinary</sl:InfoboxIdentifier>
[05]   <sl:BinaryFileParameters ContentIsXMLEntity="true"/>
[06] </sl:InfoboxReadRequest>

First the identifier for the info box to be read is specified in line 4 in sl:InfoboxIdentifier (TutorialBinary).

After this, the (empty) element sl:BinaryFileParameters must always be specified (cf. line 5). The optional ContentIsXMLEntity attribute with the value true which continues to be used here informs the Citizen Card Environment that the content of the info box can be interpreted as a set of XML nodes (not necessarily as an XML document with a single root element). The Citizen Card Environment will take account of this situation in the format of the command response (compare below).

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted for better readability.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxReadResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:BinaryFileData>
[05]     <sl:XMLContent>
[06]       <my:Customer xmlns:my="urn:my.namespace">
[07]         <my:Name>Tassilo Tester</my:Name>
[08]         <my:LastVisit>2004-12-31</my:LastVisit>
[09]       </my:Customer>
[10]     </sl:XMLContent>
[11]   </sl:BinaryFileData>
[12] </sl:InfoboxReadResponse>

The response contains sl:BinaryFileData as a single child element (lines 4 to 11). The content of the info box is encoded there by the Citizen Card Environment either as an XML structure (sl:XMLContent), or as base64-coded binary data (sl:Base64Content) at the Citizen Card Environment's discretion. However, since it has been expressly indicated in line 5 of the request that the content of the info box can be interpreted as XML, the Citizen Card Environment always returns the content as an XML structure (compare lines 5 to 10 in this context).

Downloads for this example
Further information
2.7.4.1.2 Reading of the person identity link by the private sector

This example demonstrates how to read the person identity link (IdentityLink) info box using an application from the private sector. In line with the requirements of the Austrian E-Government Act [E-GovG], the specification for the Austrian Citizen Card stipulates that the person identity link (and therefore the sourcePIN) may only be read out by an application from the public sector. For applications from the private sector, however, the person identity link can only be read out in modified form, as is described below.

Please note that you can only execute this example if the Citizen Card Environment can authenticate the application in accordance with the class certified. Thus, it is not possible to issue the request directly using the Sending interface commands form.

Request
[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxReadRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:InfoboxIdentifier>IdentityLink</sl:InfoboxIdentifier>
[05]   <sl:BinaryFileParameters ContentIsXMLEntity="true"/>
[06]   <sl:BoxSpecificParameters>
[07]     <sl:IdentityLinkDomainIdentifier>
[08]       urn:publicid:gv.at:wbpk+FN+468924i</sl:IdentityLinkDomainIdentifier>
[09]   </sl:BoxSpecificParameters>
[10] </sl:InfoboxReadRequest> 

The request is basically the same as that in example 2.7.4.1.1.

However, the final child element sl:BoxSpecificParameters in lines 6 to 9 is new. This element may contain parameters that are specific to a particular info box. The sl:IdentityLinkDomainIdentifier element can be specified as a box-specific parameter for the IdentityLink info box; this option is used here.

It contains the sourcePIN of the private sector client that wants to read out the person identity link; the sourcePIN is encoded as a URN, as specified in the Formation of SourcePINs (Source Identification Numbers) and Sector-Specific Personal Identifier (ssPINs) specification dated 30 June 2004. In this case, this is the entry number in the Register of Company Names 468924i, which is preceded by the string urn:publicid:gv.at:wbpk as a general prefix and by the code for the sourcePIN type FN, each separated by a +.

Specifying the sl:IdentityLinkDomainIdentifier parameter instructs the Citizen Card Environment not to return the original person identity link in the response, but rather a modified variant. The sourcePIN in the person identity link is replaced with the private sector-specific personal identifier (pssPIN) derived from the sourcePIN for the private sector client (compare below).

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted and shortened for better readability.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxReadResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:BinaryFileData>
[05]     <sl:XMLContent>
[06]       <saml:Assertion AssertionID="bka.gv.at-2004-05-18T17.27.12.464" 
[07]         IssueInstant="2004-05-18T17:27:12.464" 
[08]         Issuer="http://www.bka.gv.at/datenschutz/Stammzahlenregisterbehoerde" 
[09]         MajorVersion="1" MinorVersion="0" xmlns="" 
[10]         xmlns:pr="http://reference.e-government.gv.at/namespace/persondata/20020228#" 
[11]         xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" 
[12]         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
[13]         <saml:AttributeStatement>
[14]           <saml:Subject>
[15]             <saml:SubjectConfirmation>
[16]               <saml:ConfirmationMethod>
[17]                 urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</saml:ConfirmationMethod>
[18]               <saml:SubjectConfirmationData>
[19]                 <pr:Person xsi:type="pr:PhysicalPersonType">
[20]                   <pr:Identification>
[21]                     <pr:Value>q4Tt5WKrnqFJGe5pDLDkiaDEi/8=</pr:Value>
[22]                     <pr:Type>urn:publicid:gv.at:wbpk+FN+468924i</pr:Type>
[23]                   </pr:Identification>
[24]                   <pr:Name>
[25]                     <pr:GivenName>Thassilo</pr:GivenName>
[26]                     <pr:FamilyName primary="undefined">Tester</pr:FamilyName>
[27]                   </pr:Name>
[28]                   <pr:DateOfBirth>1900-01-01</pr:DateOfBirth>
[29]                 </pr:Person>
[30]               </saml:SubjectConfirmationData>
[31]             </saml:SubjectConfirmation>
[32]           </saml:Subject>
[33]           ...
[34]         </saml:AttributeStatement>

As in example 2.7.4.1.1, the response contains the modified person identity link as the content of the sl:XMLContent element (lines 5 to 71).

It is apparent that the contents of the pr:Value and pr:Type elements in lines 21 and 22 have been changed in comparison with the original person identity link. pr:Value now contains the pssPIN for the private sector specified in line 8 of the request. pr:Type refers to this.

[35]         <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[36]           <dsig:SignedInfo>
[37]             ...
[38]             <dsig:Reference URI="">
[39]               <dsig:Transforms>
[40]                 <dsig:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
[41]                   <dsig:XPath>not(ancestor-or-self::pr:Identification)</dsig:XPath>
[42]                 </dsig:Transform>
[43]                 <dsig:Transform 
[44]                   Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
[45]               </dsig:Transforms>
[46]               ...
[47]             </dsig:Reference>
[48]             <dsig:Reference 
[49]               Type="http://www.w3.org/2000/09/xmldsig#Manifest" URI="#manifest">
[50]               <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[51]               <dsig:DigestValue>npZy/EwgnfUNtLanRFQwtko35fU=</dsig:DigestValue>
[52]             </dsig:Reference>
[53]           </dsig:SignedInfo>
[54]           <dsig:SignatureValue>...</dsig:SignatureValue>
[55]           <dsig:KeyInfo>...</dsig:KeyInfo>
[56]           <dsig:Object>
[57]             <dsig:Manifest Id="manifest">
[58]               <dsig:Reference URI="">
[59]                 <dsig:Transforms>
[60]                   <dsig:Transform 
[61]                     Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
[62]                     <dsig:XPath>not(ancestor-or-self::dsig:Signature)</dsig:XPath>
[63]                   </dsig:Transform>
[64]                 </dsig:Transforms>
[65]                 ...
[66]               </dsig:Reference>
[67]             </dsig:Manifest>
[68]           </dsig:Object>
[69]         </dsig:Signature>
[70]       </saml:Assertion>
[71]     </sl:XMLContent>
[72]   </sl:BinaryFileData>
[73] </sl:InfoboxReadResponse>

To prevent this modification from rendering the person identity link useless because of the break in the electronic signature, the person identity link always contains an electronic signature with a total of two signed data areas. The first data area encompasses the whole person identity link with the exception of the pr:Identification element (cf. lines 20 to 23); the second area actually contains the whole person identity link.

The dsig:Reference element in lines 38 to 47 references the first data area. The hash value for the first data area encoded there remains valid despite the modification made.

The dsig:Reference element in lines 48 to 52 references the XMLDSIG manifest in lines 57 to 67. This XMLDSIG manifest contains a dsig:Reference (lines 58 to 66), which references the second data area, in other words the whole person identity link. The hash value encoded there is rendered invalid by the modification made.

Thus, the private sector client receives a person identity link whose signature remains basically valid, except for the result of the test of the XMLDSIG manifest which will return an error. Among other things, the private sector client can thus be sure that first name, surname and date of birth (cf. lines 25, 26 and 28) are assigned correctly to the official keys of the Citizen Card.

Note: If the private sector client also wishes to be able to rely on the correct assignment of the pssPIN to the public keys of the Citizen Card, there is a separate request available for this purpose in the sourcePIN register.

Downloads for this example
Further information

2.7.4.2 Reading an associative array

The following examples demonstrate how to read an associative-array type info box. Commands are available for reading array keys, for reading a value for a particular key and for reading key/value pairs.

2.7.4.2.1 Reading keys

This example shows how to read the keys from the standardised Certificates info box.

Request
[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxReadRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:InfoboxIdentifier>Certificates</sl:InfoboxIdentifier>
[05]   <sl:AssocArrayParameters>
[06]     <sl:ReadKeys SearchString="*"/>
[07]   </sl:AssocArrayParameters>
[08] </sl:InfoboxReadRequest>

The sl:InfoboxIdentifier element in line 4 contains the identifier for the info box to be read.

sl:AssocArrayParameters contains the parameters for the read request for an associative array. For reading keys, it contains the empty sl:ReadKeys element whose SearchString attribute contains the search term for the keys to be returned. The * wildcard may be used any number of times in the search term and stands for an unlimited sequence of characters, with the exception of /. In this case, the search term * should return all available keys of the associative array.

As an option, the UserMakesUnique attribute could be specified with the value true for sl:ReadKeys. If there were several keys that corresponded to this search term, this would instruct the Citizen Card Environment to allow the citizen to select precisely one of these keys via the user interface; this would then be the only key returned in the response.

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted for better readability.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxReadResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:AssocArrayData>
[05]     <sl:Key>SecureSignatureKeypair</sl:Key>
[06]     <sl:Key>CertifiedKeypair</sl:Key>
[07]   </sl:AssocArrayData>
[08] </sl:InfoboxReadResponse>

The response contains a single sl:AssocArrayData element (lines 4 to 7). This contains an sl:Key element with the relevant name for each available key. Thus, in this case two keys were found.

Downloads for this example
Further information
2.7.4.2.2 Reading the value for a key

This example shows how to read a value for a particular key from the standardised Certificates info box.

Request
[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxReadRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:InfoboxIdentifier>Certificates</sl:InfoboxIdentifier>
[05]   <sl:AssocArrayParameters>
[06]     <sl:ReadValue Key="SecureSignatureKeypair"/>
[07]   </sl:AssocArrayParameters>
[08] </sl:InfoboxReadRequest>

The sl:InfoboxIdentifier element in line 4 contains the identifier for the info box to be read.

sl:AssocArrayParameters contains the parameters for the read request for an associative array. For reading a value for a particular key, it contains the empty sl:ReadValue element, whose Key attribute uniquely identifies the key for which the relevant value is to be read. In this case, the value is to be read for the SecureSignatureKeypair key.

As an option, the ValuesAreXMLEntities attribute could be specified with the value true for sl:ReadValue. This would instruct the Citizen Card Environment always to return the value for the specified key as an XML structure (cf. also example 2.7.4.1.1).

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted and shortened for better readability.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxReadResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:AssocArrayData>
[05]     <sl:Pair Key="SecureSignatureKeypair">
[06]       <sl:Base64Content>MIIE...VsAAAAAAAAA==</sl:Base64Content>
[07]     </sl:Pair>
[08]   </sl:AssocArrayData>
[09] </sl:InfoboxReadResponse>

The response contains a single sl:AssocArrayData element (lines 4 to 8). This contains precisely one sl:Pair element, whose Key attribute contains the key identifier specified in the request. As the content of sl:Pair, the corresponding value is either encoded as sl:Base64Content (like the corresponding certificate here) or as sl:XMLContent.

Downloads for this example
Further information
2.7.4.2.3 Reading key/value pairs

This example shows how to read the key/value pairs from the standardised Certificates info box.

Request
[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxReadRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:InfoboxIdentifier>Certificates</sl:InfoboxIdentifier>
[05]   <sl:AssocArrayParameters>
[06]     <sl:ReadPairs SearchString="*Keypair"/>
[07]   </sl:AssocArrayParameters>
[08] </sl:InfoboxReadRequest>

The sl:InfoboxIdentifier element in line 4 contains the identifier for the info box to be read.

sl:AssocArrayParameters contains the parameters for the read request for an associative array. For reading key/value pairs, it contains the empty sl:ReadPairs element whose SearchString attribute contains the search term for the key/value pairs to be returned. The * wildcard may be used any number of times in the search term and stands for an unlimited sequence of characters, with the exception of /. In this case, the *KeyPair search term should return all keys of the associative array that end in KeyPair and the associated values.

As an option, the UserMakesUnique attribute could be specified with the value true for sl:ReadPairs. If there were several keys that corresponded to this search term, this would instruct the Citizen Card Environment to allow the citizen to select precisely one of these keys via the user interface; this would then be the only key returned in the response, together with the associated value.

As another option, the ValuesAreXMLEntities attribute could be specified with the value true for sl:ReadPairs. This would instruct the Citizen Card Environment always to return the values for the key corresponding to the search term as an XML structure (cf. also example 2.7.4.1.1).

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted and shortened for better readability.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxReadResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:AssocArrayData>
[05]     <sl:Pair Key="SecureSignatureKeypair">
[06]       <sl:Base64Content>MIIE4DCCA8ig...+x8VxVsAAAAAAAAA==</sl:Base64Content>
[07]     </sl:Pair>
[08]     <sl:Pair Key="CertifiedKeypair">
[09]       <sl:Base64Content>MIIEoDCCA4ig...cutCWhOFr6DJmgSSMc</sl:Base64Content>
[10]     </sl:Pair>
[11]   </sl:AssocArrayData>
[12] </sl:InfoboxReadResponse>

The response contains a single sl:AssocArrayData element (lines 4 to 11). For each key corresponding to the search term in the request, this element contains precisely one sl:Pair element, whose Key attribute contains the key identifier specified in the request. As the content of sl:Pair, the corresponding value is either encoded as sl:Base64Content (like the corresponding certificate here) or as sl:XMLContent.

Downloads for this example
Further information

2.7.5 Changing an info box

2.7.5.1 Changing a binary file

The following example demonstrates how to change a binary-file type info box. A binary file is changed by being rewritten in its entirety. If you wish to reproduce this example, first execute example 2.7.2.1 (creating an info box).

Request
[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxUpdateRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:InfoboxIdentifier>TutorialBinary</sl:InfoboxIdentifier>
[05]   <sl:BinaryFileParameters>
[06]     <sl:XMLContent>
[07]       <my:Customer xmlns:my="urn:my.namespace">
[08]         <my:Name>Tassilo Tester</my:Name>
[09]         <my:LastVisit>2004-12-31</my:LastVisit>
[10]       </my:Customer>
[11]     </sl:XMLContent>
[12]   </sl:BinaryFileParameters>
[13] </sl:InfoboxUpdateRequest>

The sl:InfoboxIdentifier element in line 4 contains the identifier for the info box to be changed (in this case TutorialBinary).

sl:BinaryFileParameters contains the new content of the info box to be changed. In this case, the new data is an XML structure that is thus encoded as the content of sl:XMLContent. Alternatively, the data could also be specified in base64-encoded form as content of sl:Base64Content.

Response

The corresponding response from the Citizen Card Environment should look something like this.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxUpdateResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#"/>

The request consists of the empty sl:InfoboxUpdateResponse element.

Downloads for this example
Further information

2.7.5.2 Changing an associative array

The following examples demonstrate how to change an associative-array type info box. Commands are available for adding/changing a value, changing a key and deleting a key.

2.7.5.2.1 Adding/changing a value

This example shows how a value is added to an associative array. If you wish to reproduce this example, first execute example 2.7.2.2 (creating an info box).

Request
[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxUpdateRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:InfoboxIdentifier>TutorialAssocArray</sl:InfoboxIdentifier>
[05]   <sl:AssocArrayParameters>
[06]     <sl:UpdateValue Key="Äpfel">
[07]       <sl:XMLContent>1,99</sl:XMLContent>
[08]     </sl:UpdateValue>
[09]   </sl:AssocArrayParameters>
[10] </sl:InfoboxUpdateRequest>

The sl:InfoboxIdentifier element in line 4 contains the identifier for the info box to which a value is to be added.

sl:AssocArrayParameters (lines 5 to 9) contains a single sl:UpdateValue element whose Key attribute is set to the key of the value to be changed. If – as in this case – there is not yet a value with the specified key, a new value is added to the info box with the specified key. sl:UpdateValue contains the new value for the key specified in Key; it can either be specified within the sl:XMLContent element, as in this example (if it can be represented as a set of XML nodes), or in base64-encoded form within the sl:Base64Content element.

Response

The corresponding response from the Citizen Card Environment should look something like this.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxUpdateResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#"/>

The request consists of the empty sl:InfoboxUpdateResponse element.

Downloads for this example
Further information
2.7.5.2.2 Changing a key

This example shows how to change the key in an associative array. If you wish to reproduce this example, first execute example 2.7.2.2 (creating an info box).

Request
[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxUpdateRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:InfoboxIdentifier>TutorialAssocArray</sl:InfoboxIdentifier>
[05]   <sl:AssocArrayParameters>
[06]     <sl:UpdateKey Key="Äpfel" NewKey="Äpfel Kronprinz"/>
[07]   </sl:AssocArrayParameters>
[08] </sl:InfoboxUpdateRequest>

The sl:InfoboxIdentifier element in line 4 contains the identifier for the info box in which a key is to be changed.

sl:AssocArrayParameters (lines 5 to 9) contains a single sl:UpdateKey element. The Key attribute contains the key identifier to be changed, while the NewKey attribute contains the new name for the key identifier. In this particular case, the key Äpfel is to be changed to the key Äpfel Kronprinz.

Response

Here again the response consists of the empty sl:InfoboxUpdateResponse element and is not shown again at this point.

Downloads for this example
Further information
2.7.5.2.3 Deleting a key/value pair

This example shows how to delete a key and the associated value from an associative array. If you wish to reproduce this example, first execute example 2.7.2.2 (creating an info box).

Request
[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:InfoboxUpdateRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:InfoboxIdentifier>TutorialAssocArray</sl:InfoboxIdentifier>
[05]   <sl:AssocArrayParameters>
[06]     <sl:DeletePair Key="Äpfel Kronprinz"/>
[07]   </sl:AssocArrayParameters>
[08] </sl:InfoboxUpdateRequest>

The sl:InfoboxIdentifier element in line 4 contains the identifier for the info box from which a key/value pair is to be deleted.

sl:AssocArrayParameters (lines 5 to 9) contains a single sl:DeletePair element. The Key attribute contains the name of the key that is to be deleted from the info box together with its associated value.

Response

Here again the response consists of the empty sl:InfoboxUpdateResponse element and is not shown again at this point.

Downloads for this example
Further information

2.8 Requesting properties

The following examples show how to request the properties of the Citizen Card Environment and check the status of the Citizen Card token.

2.8.1 Environment properties

This example explains how to request the properties of the Citizen Card Environment. This allows the application to read out a series of parameters that could be significant for further communication with the Citizen Card Environment, such as supported viewer formats or supported transformations in the context of XML signatures.

Request

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:GetPropertiesRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#"/>

The request consists of the empty sl:GetPropertiesRequest element.

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted for better readability.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:GetPropertiesResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:ViewerMediaType>text/plain</sl:ViewerMediaType>
[05]   <sl:ViewerMediaType>text/xml</sl:ViewerMediaType>
[06]   <sl:ViewerMediaType>application/xml</sl:ViewerMediaType>
[07]   <sl:ViewerMediaType>text/sgml</sl:ViewerMediaType>
[08]   <sl:ViewerMediaType>application/sgml</sl:ViewerMediaType>
[09]   <sl:ViewerMediaType>text/tab-separated-values</sl:ViewerMediaType>
[10]   <sl:ViewerMediaType>message/rfc822</sl:ViewerMediaType>
[11]   <sl:ViewerMediaType>text/html</sl:ViewerMediaType>
[12]   <sl:ViewerMediaType>application/xhtml+xml</sl:ViewerMediaType>

First the response contains an sl:ViewerMediaType element for each supported viewer format. This element contains the mime type for the supported viewer format. The elements in lines 4 to 12 correspond to the minimum set of viewer formats that must be supported by a Citizen Card Environment.

[13]   <sl:XMLSignatureTransform>
[14]     http://www.w3.org/TR/2001/REC-xml-c14n-20010315</sl:XMLSignatureTransform>
[15]   <sl:XMLSignatureTransform>
[16]     http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments</sl:XMLSignatureTransform>
[17]   <sl:XMLSignatureTransform>
[18]     http://www.w3.org/2001/10/xml-exc-c14n#</sl:XMLSignatureTransform>
[19]   <sl:XMLSignatureTransform>
[20]     http://www.w3.org/2001/10/xml-exc-c14n#WithComments</sl:XMLSignatureTransform>
[21]   <sl:XMLSignatureTransform>
[22]     http://www.w3.org/2000/09/xmldsig#base64</sl:XMLSignatureTransform>
[23]   <sl:XMLSignatureTransform>
[24]     http://www.w3.org/TR/1999/REC-xpath-19991116</sl:XMLSignatureTransform>
[25]   <sl:XMLSignatureTransform>
[26]     http://www.w3.org/2002/06/xmldsig-filter2</sl:XMLSignatureTransform>
[27]   <sl:XMLSignatureTransform>
[28]     http://www.w3.org/2000/09/xmldsig#enveloped-signature</sl:XMLSignatureTransform>
[29]   <sl:XMLSignatureTransform>
[30]     http://www.w3.org/TR/1999/REC-xslt-19991116</sl:XMLSignatureTransform>

Subsequently, the response contains an sl:XMLSignatureTransform element for each supported transformation algorithm for XML signatures. This element contains the URI for the supported algorithm. The elements in lines 13 to 30 correspond to the minimum set of transformation algorithms that must be supported by a Citizen Card Environment.

[31]   <sl:KeyboxIdentifier Signature="1" Encryption="0">
[32]     SecureSignatureKeypair</sl:KeyboxIdentifier>
[33]   <sl:KeyboxIdentifier Signature="1" Encryption="1">
[34]     CertifiedKeypair</sl:KeyboxIdentifier>

The identifiers for all key pairs in the Citizen Card Environment follow with the sl:KeyBoxIdentifier elements. For each key pair, a specification indicates whether it is suitable for use in the signature (Signature attribute) or in the encryption (Encryption attribute) context. The elements in lines 31 to 34 correspond to the requirements in the Standardised key and info boxes specification.

[35]   <sl:Binding Identifier="TCP/IP"/>
[36]   <sl:Binding Identifier="TLS"/>
[37]   <sl:Binding Identifier="HTTP"/>
[38]   <sl:Binding Identifier="HTTPS"/>

With the sl:Binding elements, the response subsequently contains the supported transport protocols for the XML protocol of the Security Layer. The value of sl:Binding/@Identifier contains the name of the supported transport protocol. The elements in lines 35 to 38 correspond to all those mechanisms described in the Security Layer Transport Protocols specification.

[39]   <sl:ProtocolVersion>1.0</sl:ProtocolVersion>
[40]   <sl:ProtocolVersion>1.1</sl:ProtocolVersion>
[41]   <sl:ProtocolVersion>1.2</sl:ProtocolVersion>
[42] </sl:GetPropertiesResponse>

Finally, the sl:ProtocolVersion elements specify the versions of the XML protocol of the Security Layer that are supported by the Citizen Card Environment. The elements in lines 39 to 41 mean that the Citizen Card Environment supports all protocol versions of the Security Layer that have been published to date.

Downloads for this example
Further information

2.8.2 Token status

This example explains how to check the status of the Citizen Card token. It is provided here for the sake of completeness. In practice, this (historical) command is hardly used any more.

Request

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:GetStatusRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#"/>

The request consists solely of the empty sl:GetStatusRequest element. For further options see Specification of the command.

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that the example has been formatted for better readability.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:GetStatusResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:TokenStatus>ready</sl:TokenStatus>
[05] </sl:GetStatusResponse>

The response contains a single sl:TokenStatus element, whose text content shows whether the Citizen Card token is ready (value ready) or not (value removed). In the case of a local Citizen Card Environment, this makes it possible to recognise whether or not the Citizen Card is inserted in the card reader. In the case of a server-based Citizen Card Environment, it is expected that the value ready will be returned.

Downloads for this example
Further information

2.9 Null operation

This example demonstrates how the null operation is used. As the name suggests, the Citizen Card Environment does not perform any functions when this command is called, but simply returns a static response. For the motivation behind this command, see the relevant specification.

Request

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:NullOperationRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#"/>

The request consists of the empty sl:NullOperationRequest element.

Response

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:NullOperationResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#"/>

The request consists of the empty sl:NullOperationResponse element.

Downloads for this example

Further information

2.10 Error handling

If the Citizen Card Environment was not able to process a command request correctly, it answers with an error response instead of a corresponding command response. This is an example of such an error response:

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:ErrorResponse 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:ErrorCode>4901</sl:ErrorCode>
[05]   <sl:Info>Token nicht bereit (bzw. Token nicht vorhanden)</sl:Info>
[06] </sl:ErrorResponse>

The error response always consists of two elements – sl:ErrorCode and sl:Info.

sl:ErrorCode contains a four-digit error code as text content in line with the Error codes of the Security Layer specification.

sl:Info contains a free text describing the cause of the error. This makes it easier for people to interpret.

Downloads for this example

Further information

3 Transport protocols

This section deals with sending commands to the Citizen Card Environment using the specified transport protocols TCP/IP or TLS and HTTP or HTTPS. The main focus is on the latter pair of protocols.

3.1 TCP/IP and TLS

The XML interface commands discussed in section 2 are transmitted directly via TCP/IP or TLS without further encoding or implementation/embedding.

The application thus opens a TCP/IP or TLS connection to the Citizen Card Environment and sends the corresponding XML command request. The Citizen Card Environment answers with the corresponding XML command response and then closes the connection.

You can test out the transmission of XML interface commands to a local Citizen Card Environment using TCP/IP by establishing a connection to the localhost:3495 address via a Telnet client and sending one of the XML command requests discussed in section 2.

Further information

3.2 HTTP and HTTPS

An XML command request as discussed in section 2 is transmitted via HTTP or HTTPS by being embedded in an HTTP request. To put it more precisely, the XML command request is embedded together with any other parameters (see below) in an HTTP GET or HTTP POST request. The parameters are encoded either as application/x-www-form-urlencoded or as multipart/form-data. This makes it possible to send the XML command request directly from the citizen's browser to the Citizen Card Environment using an HTML form.

The response from the Citizen Card Environment depends on the other form parameters that may have been transmitted together with the actual XML command request in the HTTP request. You will find details of this in the following subsections.

3.2.1 Result returned to the browser

In the simplest scenario, the Citizen Card Environment returns the XML command response to an XML command request received via HTTP request from the citizen's browser directly in the corresponding HTTP response to the browser.

3.2.1.1 Result as XML

If only the XML command request is specified in the HTTP request as XMLRequest form parameter, but no other form parameters are specified, the Citizen Card Environment sends the XML command response directly to the browser as the payload of the corresponding HTTP response.

The following example demonstrates this scenario. The NullOperation command is transmitted.

HTML page with form

Here you can see the HTML page with the form to be transmitted to the Citizen Card Environment. Please note that for better readability, the example has been formatted and line breaks have been added (indicated by the \ character at the end of a line).

[01] <html>
[02]   <head>
[03]     <title>Direkte Ansteuerung</title>
[04]   </head>
[05]   <body>
[06]     <p>Direktes Senden des Befehls <code>NullOperation</code>.</p>
[07]     <form method="post" action="http://127.0.0.1:3495/http-security-layer-request">
[08]       <input name="XMLRequest" type="hidden" 
[09]       value="<?xml version='1.0' encoding='UTF-8'?><NullOperationRequest \
[10] xmlns='http://www.buergerkarte.at/namespaces/securitylayer/1.2#'/>"/>
[11]       <input type="submit" value="Request absenden"/>
[12]     </form>
[13]   </body>
[14] </html>

Lines 7 to 12 indicate the HTML form whose form data is to be transmitted to the Citizen Card Environment via HTTP POST (compare the method attribute in line 7) (compare the action attribute in line 7; http-security-layer-request must always be used in precisely this form (written this way) as a path component in the URL).

Lines 8 to 10 contain the details of the XML interface command. The name of the form element must always be XMLRequest. The value attribute contains the XML interface command; please note that escaping is required within the attribute value, e.g. for the < character (<). Since the XML interface command is not supposed to be visible to the citizen, the form element has been defined as hidden (compare the type attribute in line 8).

HTTP request

Here you can see the HTTP request that results from sending the form in the HTML page above. Please note that line breaks have been added to the example (indicated by the \ character at the end of a line) for better readability.

[01] POST /http-security-layer-request HTTP/1.1
[02] Host: localhost
[03] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
[04] Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,\
[05] image/png,*/*;q=0.5
[06] Accept-Language: de-at,de;q=0.7,en;q=0.3
[07] Accept-Encoding: gzip,deflate
[08] Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
[09] Keep-Alive: 300
[10] Connection: keep-alive
[11] Content-Type: application/x-www-form-urlencoded
[12] Content-Length: 183
[13] 
[14] XMLRequest=%3C%3Fxml+version%3D%271.0%27+encoding%3D%27UTF-8%27%3F%3E%3CNullOperationRequest\
[15] +xmlns%3D%27http%3A%2F%2Fwww.buergerkarte.at%2Fnamespaces%2Fsecuritylayer%2F1.2%23%27%2F%3E

It is apparent in line 11 that the form data has been transmitted as application/x-www-form-urlencoded. The XMLRequest form parameter can be seen in lines 14 and 15 with the appropriate encoding.

HTTP response

Below you will see the HTTP response returned by the Citizen Card Environment to the citizen's browser. Please note that line breaks have been added to the example (indicated by the \ character) for better readability.

[00] HTTP/1.1 200 OK
[01] Server: citizen-card-environment/1.2 trustDeskbasic/2.2.3-developer
[02] Content-Type: text/xml; charset=UTF-8
[03] Content-Length: 133
[04] 
[05] <?xml version="1.0" encoding="UTF-8"?><sl:NullOperationResponse \
[06] xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#"/>

In line 1, the Citizen Card Environment identifies itself with the Server header.

Lines 5 and 6 contain the XML command response from the Citizen Card Environment as the payload of the HTTP response. This is why the Content-Type header in line 2 contains the corresponding mime type text/xml.

Downloads for this example
Further information

3.2.1.2 Transformed result as HTML

If another StylesheetURL form parameter is specified in the HTTP request in addition to the XML command request as form parameter XMLRequest, the Citizen Card Environment transforms the XML command response e.g. into an HTML document using the style sheet referenced in StylesheetURL, so as to return this document as the payload of the corresponding HTTP response to the browser.

The following example demonstrates this scenario. The GetPropertiesRequest command is transmitted.

HTML page with form

Here you can see the HTML page with the form to be transmitted to the Citizen Card Environment. Please note that for better readability, the example has been formatted and line breaks have been added (indicated by the \ character at the end of a line).

[01] <html>
[02]   <head>
[03]     <title>Direkte Ansteuerung mit Stylesheet-Transformation</title>
[04]   </head>
[05]   <body>
[06]     <p>Direktes Senden des Befehls <code>GetProperties</code> mit Stylesheet-\
[07] Transformation der Befehlsantwort.</p>
[08]     <form method="post" action="http://127.0.0.1:3495/http-security-layer-request">
[09]       <input name="XMLRequest" type="hidden" 
[10]         value="<?xml version='1.0' encoding='UTF-8'?><GetPropertiesRequest \
[11] xmlns='http://www.buergerkarte.at/namespaces/securitylayer/1.2#'/>"/>
[12]       <input name="StylesheetURL" type="hidden" 
[13]         value="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514\
[14] /tutorial/examples/bindings/stylesheet/Stylesheet.xslt"/>
[15]       <input type="submit" value="Request absenden"/>
[16]     </form>
[17]   </body>
[18] </html>

Unlike in example 3.2.1.1, the StylesheetURL form parameter is also specified here in lines 12 to 14. The value of the value attribute contains a URL for the style sheet to be used by the Citizen Card Environment to transform the command response.

HTTP request

Here you can see the HTTP request that results from the transmission of the form in the HTML page above. Please note that line breaks have been added to the example (indicated by the \ character at the end of a line) for better readability.

[01] POST /http-security-layer-request HTTP/1.1
[02] Host: localhost
[03] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 \
[04] Firefox/1.0
[05] Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;\
[06] q=0.8,image/png,*/*;q=0.5
[07] Accept-Language: de-at,de;q=0.7,en;q=0.3
[08] Accept-Encoding: gzip,deflate
[09] Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
[10] Keep-Alive: 300
[11] Connection: keep-alive
[12] Content-Type: application/x-www-form-urlencoded
[13] Content-Length: 355
[14] 
[15] XMLRequest=%3C%3Fxml+version%3D%271.0%27+encoding%3D%27UTF-8%27%3F%3E%3CGetProperties\
[16] Request+xmlns%3D%27http%3A%2F%2Fwww.buergerkarte.at%2Fnamespaces%2Fsecuritylayer\
[17] %2F1.2%23%27%2F%3E&StylesheetURL=http%3A%2F%2Fwww.buergerkarte.at%2Fkonzept%2F\
[18] securitylayer%2Fspezifikation%2F20040514%2Ftutorial%2Fexamples%2Fbindings%2F
[19] stylesheet%2FStylesheet.xslt

It is apparent in line 21 that the form data has been transmitted as application/x-www-form-urlencoded. The XMLRequest and StylesheetURL form parameters can be seen in lines 15 to 19 with the appropriate encoding.

HTTP response

Below you will see the HTTP response returned by the Citizen Card Environment to the citizen's browser. Please note that for better readability, the example has been shortened and line breaks have been added (indicated by the \ character).

[01] HTTP/1.1 200 OK
[02] Server: citizen-card-environment/1.2 trustDeskbasic/2.2.3-developer
[03] Content-Type: text/html; charset=UTF-8
[04] Content-Length: 2441
[05] 
[06] <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" \
[07] "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
[08] <html xmlns="http://www.w3.org/1999/xhtml" \
[09] xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[10] <head>
[11] <title>Stylesheet: Resultat</title>
[12] </head>
[13] <body><table xmlns="" border="1" bgcolor="silver">
[14] <tbody>
[15] <tr>
[16] <td>Anzeigeformat</td><td><code>text/plain</code></td></tr>
[17] <tr>
[18] ...
[19] <tr>
[20] <td>XMLDSIG-Transformation</td><td><code>http://www.w3.org/TR/2001/\
[21] REC-xml-c14n-20010315</code></td>
[22] </tr>
[23] ...
[24] <tr>
[25] <td>Schlüssel (Signatur)</td><td><code>SecureSignatureKeypair</code></td>
[26] </tr>
[27] ...
[28] <tr>
[29] <td>Transport-Protokoll</td><td><code>TCP/IP</code></td>
[30] </tr>
[31] ...
[32] <tr>
[33] <td>Protokoll-Version</td><td><code>1.0</code></td>
[34] </tr>
[35] ...
[36] </tbody>
[37] </table>
[38] </body>
[39] </html>

Unlike in example 3.2.1.1, the payload (cf. lines 6 to 39) does not contain the XML command response, but rather the result of the transformation with the style sheet referenced in StylesheetURL. The transformation has generated an HTML document; this is why the Content-Type header in line 2 contains the corresponding mime type text/html.

Downloads for this example
Further information

3.2.2 Result returned to the application server

By specifying the DataURL form parameter in the HTTP request, the Citizen Card Environment can be instructed to return the XML command response to the application server referenced in the DataURL instead of to the browser in the HTTP response.

The question which data is finally transmitted back to the browser in the HTTP response from the Citizen Card Environment depends both on the reaction of the application server and on any other form parameters specified in the HTTP request from the browser.

The following examples demonstrate a number of combination options.

Note: You can try out the following examples for yourself. You will find the requisite application here in the form of a J2EE web application as a web archive. Use the web application in such a way that its root context can be reached under the URL http://localhost:8080/SL12Tutorial/ or via HTTPS under the URL http://localhost:8443/SL12Tutorial/. Please note that the web application should solely be seen as a prototype and is not intended for real use (insufficient robustness and modularity).

3.2.2.1 Asynchronous user guidance with RedirectURL and DataURL

In the next example, two more form parameters are specified in the HTTP request as XMLRequest form parameters in addition to the XML command request:

The combination of these form parameters results in the following sequence in the example:

  1. The citizen sends an HTTP request to the Citizen Card Environment with the XMLRequest (in this specific case with the GetProperties command) and the two additional form parameters DataURL and RedirectURL.
  2. The Citizen Card Environment immediately responds to the citizen's HTTP request with an HTTP Redirect (Code 302 or 303) to the location specified in RedirectURL. This location is part of the application and operates as a wait loop in which the citizen is held until the Citizen Card Environment's response arrives at the application (see step 3).
  3. The Citizen Card Environment processes the XML command request and transmits the XML command response in an HTTP POST request to the location specified in the DataURL which is part of the application.
  4. The application confirms the correct receipt of the XML command response to the Citizen Card Environment in the HTTP response.
  5. The application processes the command response and answers the citizen with the next step in the process instead of with the wait page.
HTML form

The following HTML form has been generated dynamically by the application and can be loaded from the URL http://localhost:8080/SL12Tutorial/Redirect provided that the web application is installed. Please note that for better readability, it has been formatted and line breaks have been added (indicated by the \ character at the end of a line).

[01] <html>
[02]   <head>
[03]     <title>Redirect: Start</title>
[04]   </head>
[05]   <body>
[06]     <form method="post" action="http://127.0.0.1:3495/http-security-layer-request">
[07]       <input name="XMLRequest" type="hidden" 
[08]         value="<?xml version='1.0' encoding='UTF-8'?><GetPropertiesRequest \
[09] xmlns='http://www.buergerkarte.at/namespaces/securitylayer/1.2#'/>" />
[10]       <input name="DataURL" type="hidden" 
[11]         value="http://localhost:8080/SL12Tutorial/Redirect;jsessionid=\
[12] 546C378088AAE921AE9BEE488582580E?use=dataurl" />
[13]       <input name="RedirectURL" type="hidden" 
[14]         value="http://localhost:8080/SL12Tutorial/Redirect;jsessionid=\
[15] 546C378088AAE921AE9BEE488582580E?use=redirecturl" />
[16]       <input name="Request absenden" type="submit" />
[17]     </form>
[18]   </body>
[19] </html>

The DataURL form parameter is encoded in lines 10 to 12, while the RedirectURL form parameter is encoded in lines 13 to 15.

It is apparent that both URLs contain the session ID required for subsequently linking the browser of the citizen, which will remain in the wait loop, with the XML command response, which will be transmitted from the Citizen Card Environment to the application. The session ID must be included in the URLs because it cannot be provided by means of cookies, as the application is involved with two different clients (the browser of the citizen and the Citizen Card Environment).

HTTP request from the browser to the Citizen Card Environment

Here you can see the HTTP request that results from the transmission of the form in the HTML page above. Please note that line breaks have been added (indicated by the \ character at the end of a line) for better readability.

[01] POST /http-security-layer-request HTTP/1.1
[02] Host: 127.0.0.1
[03] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 \
[04] Firefox/1.0
[05] Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;\
[06] q=0.8,image/png,*/*;q=0.5
[07] Accept-Language: de-at,de;q=0.7,en;q=0.3
[08] Accept-Encoding: gzip,deflate
[09] Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
[10] Keep-Alive: 300
[11] Connection: keep-alive
[12] Content-Type: application/x-www-form-urlencoded
[13] Content-Length: 467
[14] 
[15] XMLRequest=%3C%3Fxml+version%3D%271.0%27+encoding%3D%27UTF-8%27%3F%3E%3CGetPropertiesRequest\
[16] +xmlns%3D%27http%3A%2F%2Fwww.buergerkarte.at%2Fnamespaces%2Fsecuritylayer%2F1.2%23%27%2F%3E&\
[17] DataURL=http%3A%2F%2Flocalhost%3A8080%2FSL12Tutorial%2FRedirect%3Bjsessionid%3D546C378088AAE\
[18] 921AE9BEE488582580E%3Fuse%3Ddataurl&RedirectURL=http%3A%2F%2Flocalhost%3A8080%2FSL12Tutorial\
[19] %2FRedirect%3Bjsessionid%3D546C378088AAE921AE9BEE488582580E%3Fuse%3Dredirecturl&Request+absenden
HTTP response from the Citizen Card Environment to the browser

Below you will see the HTTP response returned by the Citizen Card Environment to the browser. Please note that line breaks have been added (indicated by the \ character at the end of a line) for better readability.

[01] HTTP/1.1 302 Object Moved
[02] Server: citizen-card-environment/1.2 trustDeskbasic/2.2.3-developer
[03] Location: http://localhost:8080/SL12Tutorial/Redirect;jsessionid=\
[04] 546C378088AAE921AE9BEE488582580E?use=redirecturl

You can see that an HTTP Redirect (compare code 302 in line 1) was sent. The Location header contains the value from the RedirectURL form parameter.

HTTP request/response to/from RedirectURL

The HTTP request from the browsers to the RedirectURL and the HTTP response from the underlying application are shown below. Please note that line breaks have been added to them (indicated by the \ character at the end of a line) for better readability.

[01] GET /SL12Tutorial/Redirect;jsessionid=546C378088AAE921AE9BEE488582580E?\
[02] use=redirecturl HTTP/1.1
[03] Host: 127.0.0.1
[04] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 \
[05] Firefox/1.0
[06] Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;\
[07] q=0.8,image/png,*/*;q=0.5
[08] Accept-Language: de-at,de;q=0.7,en;q=0.3
[09] Accept-Encoding: gzip,deflate
[10] Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
[11] Keep-Alive: 300
[12] Connection: keep-alive
[01] HTTP/1.1 200 OK
[02] Content-Type: text/html
[03] Content-Length: 340
[04] Date: Mon, 27 Dec 2004 20:17:21 GMT
[05] Server: Apache Coyote/1.0
[06] 
[07] <html>
[08] <head>
[09] <title>Redirect: Warteschleife</title>
[10] <meta http-equiv="refresh" content="10; URL=http://localhost:8080/SL12Tutorial/\
[11] Redirect;jsessionid=546C378088AAE921AE9BEE488582580E?use=redirecturl"/>
[12] </head>
[13] <body>
[14] <p>Bitte warten. Sobald die Antwort von der BKU eingetroffen ist, wird sie \
[15] hier angezeigt.</p>
[16] </body>
[17] </html>

The application's response page is designed as a wait loop. Line 10 of the HTML page contains a meta tag that causes the browser to reload the page every 10 seconds.

HTTP request from the Citizen Card Environment to DataURL

Next you will see the HTTP request from the Citizen Card Environment to the application behind the DataURL. Among other things, this contains the XML command response. Please note that, for better readability, it has been shortened (indicated by ...) and line breaks have been added (indicated by the \ character at the end of a line).

[01] POST /SL12Tutorial/Redirect;jsessionid=546C378088AAE921AE9BEE488582580E?\
[02] use=dataurl HTTP/1.1
[03] Referer: localhost
[04] User-Agent: citizen-card-environment/1.2 trustDeskbasic/2.2.3-developer
[05] Content-Type: application/x-www-form-urlencoded
[06] Host: 127.0.0.1
[07] Content-Length: 2275
[08] Connection: Keep-Alive
[09] Cache-Control: no-cache
[10] 
[11] XMLResponse=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%0D%0A%3C\
[12] GetPropertiesResponse+xmlns%3D%22http%3A%2F%2Fwww.buergerkarte.at%2Fnamespaces%\
[13] ...%3C%2FGetPropertiesResponse%3E&ResponseType=HTTP-Security-Layer-RESPONSE

This request always involves HTTP POST, as is also apparent in line 1.

Line 4 contains the obligatory identification of the Citizen Card Environment as user agent.

The payload contains a series of form parameters that (as in this example) can be encoded as application/x-www-form-urlencoded or multipart/form-data. The following parameters must always be included (as they are in this case): XMLResponse with the XML command response and ResponseType with the fixed value HTTP-Security-Layer-RESPONSE.

HTTP response from DataURL to the Citizen Card Environment

The HTTP response from the application behind the DataURL to the Citizen Card Environment is shown below. Please note that line breaks have been added (indicated by the \ character at the end of a line) for better readability.

[01] HTTP/1.1 200 OK
[02] Content-Type: text/plain
[03] Content-Length: 5
[04] Date: Mon, 27 Dec 2004 20:17:42 GMT
[05] Server: Apache Coyote/1.0
[06] 
[07] <ok/>

This confirms that the application has received the XML command correctly. The payload of the HTTP response must consist of the <ok/> string written exactly this way. The Content-Type header may either contain the value text/xml or text/plain (as in line 2 here) or text/html.

Final HTTP response from RedirectURL

Lastly, the final response from the application behind the RedirectURL to the citizen's browser is also shown below. This is transmitted as soon as the application has evaluated the XML command response from the Citizen Card Environment. Please note that for better readability, it has been shortened (indicated by the ...) wurde.

[01] HTTP/1.1 200 OK
[02] Content-Type: text/html
[03] Content-Length: 1987
[04] Date: Mon, 27 Dec 2004 20:17:51 GMT
[05] Server: Apache Coyote/1.0
[06] 
[07] <html>
[08] <head>
[09] <title>Redirect: Synchronisation erfolgreich</title>
[10] </head>
[11] <body>
[12] <p>Die Antwort von der BKU ist eingetroffen:</p>
[13] <p><pre><?xml version="1.0" encoding="UTF-8"?>
[14] <GetPropertiesResponse xmlns="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[15] ...
[16] </GetPropertiesResponse></pre></p>
[17] </body>
[18] </html>
Downloads for this example
Further information

3.2.2.2 Synchronous user guidance with DataURL

In the next example, another form parameter is specified in the HTTP request as an XMLRequest form parameter in addition to the XML command request:

The following sequence is implemented in the example by combining this form parameter with a response from the application server that has been modified in comparison with example 3.2.2.1:

  1. The citizen sends an HTTP request to the Citizen Card Environment with the XMLRequest (in this specific case with the InfoBoxAvailable command) and the additional form parameter DataURL.
  2. The Citizen Card Environment processes the XML command request and transmits the XML command response in an HTTP POST request to the location specified in the DataURL which is part of the application.
  3. The application answers the Citizen Card Environment in the HTTP response with any data in the payload, e.g. an HTML document that represents the next step in the process.
  4. As a response to the HTTP request in step 1, the Citizen Card Environment sends the citizen in the HTTP response precisely the payload it previously received from the application in step 3.
HTML form

The following HTML form has been generated dynamically by the application and can be loaded from the URL http://localhost:8080/SL12Tutorial/DataURL provided that the web application is installed. Please note that for better readability, it has been formatted and line breaks have been added (indicated by the \ character at the end of a line).

[01] <html>
[02]   <head>
[03]     <title>DataURL: Start</title>
[04]   </head>
[05]   <body>
[06]     <form method="post" action="http://127.0.0.1:3495/http-security-layer-request">
[07]       <input name="XMLRequest" type="hidden" 
[08]         value="<?xml version='1.0' encoding='UTF-8'?><InfoboxAvailableRequest \
[09] xmlns='http://www.buergerkarte.at/namespaces/securitylayer/1.2#'/>" />
[10]       <input name="DataURL" type="hidden" 
[11]         value="http://localhost:8080/SL12Tutorial/DataURL?use=dataurl" />
[12]       <input name="Request absenden" type="submit" />
[13]     </form>
[14]   </body>
[15] </html>

The DataURL form parameter is encoded in lines 10 to 12.

HTTP request from the browser to the Citizen Card Environment

Here you can see the HTTP request that results from the transmission of the form in the HTML page above. Please note that line breaks have been added (indicated by the \ character at the end of a line) for better readability.

[01] POST /http-security-layer-request HTTP/1.1
[02] Host: 127.0.0.1
[03] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 \
[04] Firefox/1.0
[05] Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;\
[06] q=0.8,image/png,*/*;q=0.5
[07] Accept-Language: de-at,de;q=0.7,en;q=0.3
[08] Accept-Encoding: gzip,deflate
[09] Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
[10] Keep-Alive: 300
[11] Connection: keep-alive
[12] Content-Type: application/x-www-form-urlencoded
[13] Content-Length: 284
[14] 
[15] XMLRequest=%3C%3Fxml+version%3D%271.0%27+encoding%3D%27UTF-8%27%3F%3E%3CInfobox\
[16] AvailableRequest+xmlns%3D%27http%3A%2F%2Fwww.buergerkarte.at%2Fnamespaces%2Fsec\
[17] uritylayer%2F1.2%23%27%2F%3E&DataURL=http%3A%2F%2Flocalhost%3A8080%2FSL12Tutori\
[18] al%2FDataURL%3Fuse%3Ddataurl&Request+absenden
HTTP request from the Citizen Card Environment to DataURL

Next you will see the HTTP request from the Citizen Card Environment to the application behind the DataURL. Among other things, the request contains the XML command response. Please note that line breaks have been added (indicated by the \ character at the end of a line) for better readability.

[01] POST /SL12Tutorial/DataURL?use=dataurl HTTP/1.1
[02] Referer: localhost
[03] User-Agent: citizen-card-environment/1.2 trustDeskbasic/2.2.3-developer
[04] Content-Type: application/x-www-form-urlencoded
[05] Host: 127.0.0.1
[06] Content-Length: 763
[07] Connection: Keep-Alive
[08] Cache-Control: no-cache
[09] 
[10] XMLResponse=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%0D%0A%3C\
[11] sl%3AInfoboxAvailableResponse+xmlns%3Asl%3D%22http%3A%2F%2Fwww.buergerkarte.at%\
[12] 2Fnamespaces%2Fsecuritylayer%2F1.2%23%22%3E%0D%0A%3Csl%3AInfoboxIdentifier%3ECe\
[13] rtificates%3C%2Fsl%3AInfoboxIdentifier%3E%0D%0A%3Csl%3AInfoboxIdentifier%3EIden\
[14] tityLink%3C%2Fsl%3AInfoboxIdentifier%3E%0D%0A%3Csl%3AInfoboxIdentifier%3ECompre\
[15] ssedIdentityLink%3C%2Fsl%3AInfoboxIdentifier%3E%0D%0A%3Csl%3AInfoboxIdentifier%\
[16] 3EMandates%3C%2Fsl%3AInfoboxIdentifier%3E%0D%0A%3Csl%3AInfoboxIdentifier%3ETuto\
[17] rialBinary%3C%2Fsl%3AInfoboxIdentifier%3E%0D%0A%3Csl%3AInfoboxIdentifier%3ETuto\
[18] rialAssocArray%3C%2Fsl%3AInfoboxIdentifier%3E%0D%0A%3C%2Fsl%3AInfoboxAvailableR\
[19] esponse%3E&ResponseType=HTTP-Security-Layer-RESPONSE

This request again involves HTTP POST, as is apparent in line 1.

Line 3 contains the obligatory identification of the Citizen Card Environment as user agent.

The payload contains a series of form parameters that can be encoded as application/x-www-form-urlencoded (as in this example) or multipart/form-data. The following parameters must always be included (as they are in this case): XMLResponse with the XML command response and ResponseType with the fixed value HTTP-Security-Layer-RESPONSE.

HTTP response from DataURL to the Citizen Card Environment

The HTTP response from the application behind the DataURL to the Citizen Card Environment is shown below. Please note that line breaks have been added (indicated by the \ character at the end of a line) for better readability.

[01] HTTP/1.1 200 OK
[02] Content-Type: text/html
[03] Content-Length: 773
[04] Date: Mon, 27 Dec 2004 21:21:10 GMT
[05] Server: Apache Coyote/1.0
[06] 
[07] <html>
[08] <head>
[09] <title>DataURL: Auswertung</title>
[10] </head>
[11] <body>
[12] <p>Die Antwort von der BKU ist eingetroffen:</p>
[13] <p><pre style="background-color: silver;"><?xml version="1.0" encoding="UTF-8"?>
[14] <sl:InfoboxAvailableResponse xmlns:sl="http://www.buergerkarte.at/namespaces/\
[15] securitylayer/1.2#">
[16] <sl:InfoboxIdentifier>Certificates</sl:InfoboxIdentifier>
[17] <sl:InfoboxIdentifier>IdentityLink</sl:InfoboxIdentifier>
[18] <sl:InfoboxIdentifier>CompressedIdentityLink</sl:InfoboxIdentifier>
[19] <sl:InfoboxIdentifier>Mandates</sl:InfoboxIdentifier>
[20] <sl:InfoboxIdentifier>TutorialBinary</sl:InfoboxIdentifier>
[21] <sl:InfoboxIdentifier>TutorialAssocArray</sl:InfoboxIdentifier>
[22] </sl:InfoboxAvailableResponse></pre></p>
[23] </body>
[24] </html>

In contrast to example 3.2.2.1, the payload of the HTTP response does not consist of a simple <ok/> string, but of an HTML document (cf. lines 7 to 24). The next and last step is for the Citizen Card Environment to send this HTML document to the citizen's browser in the HTTP response.

HTTP response from the Citizen Card Environment to the browser

Finally below, you will also find the HTTP response from the Citizen Card Environment to the citizen's browser. Please note that line breaks have been added (indicated by the \ character at the end of a line) for better readability.

[01] HTTP/1.1 200 OK
[02] Content-Type: text/html
[03] Content-Length: 773
[04] Date: Mon, 27 Dec 2004 21:21:10 GMT
[05] Server: Apache Coyote/1.0
[06] 
[07] <html>
[08] <head>
[09] <title>DataURL: Auswertung</title>
[10] </head>
[11] <body>
[12] <p>Die Antwort von der BKU ist eingetroffen:</p>
[13] <p><pre style="background-color: silver;"><?xml version="1.0" encoding="UTF-8"?>
[14] <sl:InfoboxAvailableResponse xmlns:sl="http://www.buergerkarte.at/namespaces/\
[15] securitylayer/1.2#">
[16] <sl:InfoboxIdentifier>Certificates</sl:InfoboxIdentifier>
[17] <sl:InfoboxIdentifier>IdentityLink</sl:InfoboxIdentifier>
[18] <sl:InfoboxIdentifier>CompressedIdentityLink</sl:InfoboxIdentifier>
[19] <sl:InfoboxIdentifier>Mandates</sl:InfoboxIdentifier>
[20] <sl:InfoboxIdentifier>TutorialBinary</sl:InfoboxIdentifier>
[21] <sl:InfoboxIdentifier>TutorialAssocArray</sl:InfoboxIdentifier>
[22] </sl:InfoboxAvailableResponse></pre></p>
[23] </body>
[24] </html>

A comparison with the HTTP response from the application to the Citizen Card Environment shows that the two responses are identical.

Downloads for this example
Further information

3.2.2.3 Using forwarding parameters and forwarding fields

The procedure in the following example is basically the same as in example 3.2.2.2. In addition, the use of forwarding parameters and forwarding headers is demonstrated:

If form fields that must follow a particular nomenclature are specified in the HTTP request to the Citizen Card Environment, these are forwarded to the application in identical form together with the XML command response in the HTTP request of the Citizen Card Environment. Forwarding parameters also appear there as form parameters, while forwarding headers are encoded as HTTP headers.

There is a practical scenario showing the use of a forwarding parameter in example 3.2.3.2.

HTML form

The following HTML form has been generated dynamically by the application and can be loaded from the URL http://localhost:8080/SL12Tutorial/PassOn provided that the web application is installed. Please note that for better readability, it has been formatted and line breaks have been added (indicated by the \ character at the end of a line).

[01] <html>
[02]   <head>
[03]     <title>Weitergabe: Start</title>
[04]   </head>
[05]   <body>
[06]     <form method="post" action="http://127.0.0.1:13495/http-security-layer-request">
[07]       <input name="XMLRequest" type="hidden" 
[08]         value="<?xml version='1.0' encoding='UTF-8'?><NullOperationRequest \
[09] xmlns='http://www.buergerkarte.at/namespaces/securitylayer/1.2#'/>" />
[10]       <input name="DataURL" type="hidden" 
[11]         value="http://localhost:18080/SL12Tutorial/PassOn?use=dataurl" />
[12]       <input name="WeitergabeParameter_" type="hidden" 
[13]         value="Inhalt des Weitergabe-Parameters" />
[14]       <input name="WeitergabeHeader__" type="hidden" 
[15]         value="X-Test-Weitergabe: Inhalt des Weitergabe-Headers" />
[16]       <input name="Request absenden" type="submit" />
[17]     </form>
[18]   </body>
[19] </html>

In addition to the already familiar form parameters XMLRequest (containing the NullOperation command) and DataURL, you will also find the forwarding parameter WeitergabeParameter_ (qualified as such by a following underscore _) in lines 12 and 13, and the forwarding header WeitergabeHeader__ (qualified as such by a following double underscore __) in lines 14 and 15. Please note that in the case of a forwarding header, the name of the HTTP header is not defined by the name attribute (cf. line 14), but rather the value attribute (cf. line 15) contains both the name and the value of the HTTP header (the name of the header in this particular case is X-Test-Weitergabe and the value of the header is Inhalt des Weitergabe-Headers).

HTTP request from the browser to the Citizen Card Environment

Here you can see the HTTP request that results from the transmission of the form in the HTML page above. Please note that line breaks have been added to it (indicated by the \ character at the end of a line) for better readability.

[01] POST /http-security-layer-request HTTP/1.1
[02] Host: 127.0.0.1
[03] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 \
[04] Firefox/1.0
[05] Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;\
[06] q=0.8,image/png,*/*;q=0.5
[07] Accept-Language: de-at,de;q=0.7,en;q=0.3
[08] Accept-Encoding: gzip,deflate
[09] Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
[10] Keep-Alive: 300
[11] Connection: keep-alive
[12] Content-Type: application/x-www-form-urlencoded
[13] Content-Length: 404
[14] 
[15] XMLRequest=%3C%3Fxml+version%3D%271.0%27+encoding%3D%27UTF-8%27%3F%3E%3CNullOpe\
[16] rationRequest+xmlns%3D%27http%3A%2F%2Fwww.buergerkarte.at%2Fnamespaces%2Fsecuri\
[17] tylayer%2F1.2%23%27%2F%3E&DataURL=http%3A%2F%2Flocalhost%3A8080%2FSL12Tutorial%\
[18] 2FPassOn%3Fuse%3Ddataurl&WeitergabeParameter_=Inhalt+des+Weitergabe-Parameters&\
[19] WeitergabeHeader__=X-Test-Weitergabe%3A+Inhalt+des+Weitergabe-Headers&Request+a\
[20] bsenden
HTTP request from the Citizen Card Environment to DataURL

Next you will see the HTTP request from the Citizen Card Environment to the application behind the DataURL. Among other things, this contains the XML command response, the forwarding parameter WeitergabeParameter_, and the forwarding header X-Test-Weitergabe. Please note that line breaks have been added to the HTTP request (indicated by the \ character at the end of a line) for better readability.

[01] POST /SL12Tutorial/PassOn?use=dataurl HTTP/1.1
[02] Referer: localhost
[03] User-Agent: citizen-card-environment/1.2 trustDeskbasic/2.2.3-developer
[04] Content-Type: application/x-www-form-urlencoded
[05] X-Test-Weitergabe: Inhalt des Weitergabe-Headers
[06] Host: 127.0.0.1
[07] Content-Length: 291
[08] Connection: Keep-Alive
[09] Cache-Control: no-cache
[10] 
[11] XMLResponse=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%3Csl%3AN\
[12] ullOperationResponse+xmlns%3Asl%3D%22http%3A%2F%2Fwww.buergerkarte.at%2Fnamespa\
[13] ces%2Fsecuritylayer%2F1.2%23%22%2F%3E&WeitergabeParameter_=Inhalt+des+Weitergab\
[14] e-Parameters&ResponseType=HTTP-Security-Layer-RESPONSE

The forwarding header X-Test-Weitergabe can be seen in line 5.

The forwarding parameter WeitergabeParameter_ can be seen in the payload in lines 13 and 14.

HTTP response from DataURL to the Citizen Card Environment

The HTTP response from the application behind the DataURL to the Citizen Card Environment is shown below. Please note that line breaks have been added to it (indicated by the \ character at the end of a line) for better readability.

[01] HTTP/1.1 200 OK
[02] Content-Type: text/html
[03] Content-Length: 479
[04] Date: Mon, 27 Dec 2004 22:03:58 GMT
[05] Server: Apache Coyote/1.0
[06] 
[07] <html>
[08] <head>
[09] <title>Weitergabe: Auswertung</title>
[10] </head>
[11] <body>
[12] <p>Der Wert des Weitergabe-Parameters <code style="background-color: silver;">\
[13] WeitergabeParameter_</code> lautet: <code style="background-color: silver;">\
[14] Inhalt des Weitergabe-Parameters</code></p>
[15] <p>Der Wert des Weitergabe-Headers <code style="background-color: silver;">\
[16] X-Test-Weitergabe</code> lautet: <code style="background-color: silver;">\
[17] Inhalt des Weitergabe-Headers</code></p>
[18] </body>
[19] </html>

The application has evaluated the HTTP request of the Citizen Card Environment and has generated a corresponding HTML document from this, which is subsequently forwarded by the Citizen Card Environment to the citizen's browser.

HTTP response from the Citizen Card Environment to the browser

Finally below, you will also find the HTTP response from the Citizen Card Environment to the citizen's browser. Please note that line breaks have been added to it (indicated by the \ character at the end of a line) for better readability.

[01] HTTP/1.1 200 OK
[02] Content-Type: text/html
[03] Content-Length: 479
[04] Date: Mon, 27 Dec 2004 22:03:58 GMT
[05] Server: Apache Coyote/1.0
[06] 
[07] <html>
[08] <head>
[09] <title>Weitergabe: Auswertung</title>
[10] </head>
[11] <body>
[12] <p>Der Wert des Weitergabe-Parameters <code style="background-color: silver;">\
[13] WeitergabeParameter_</code> lautet: <code style="background-color: silver;">\
[14] Inhalt des Weitergabe-Parameters</code></p>
[15] <p>Der Wert des Weitergabe-Headers <code style="background-color: silver;">\
[16] X-Test-Weitergabe</code> lautet: <code style="background-color: silver;">\
[17] Inhalt des Weitergabe-Headers</code></p>
[18] </body>
[19] </html>
Downloads for this example
Further information

3.2.2.4 Command cascading via DataURL

This example is intended to demonstrate another variation of the basic procedure in example 3.2.2.2.

So far, two possible responses by the application server behind the DataURL to the HTTP request of the Citizen Card Environment have been demonstrated: On the one hand, the simple confirmation that the XML command response has been received and on the other, the transmission of an HTML document (for example) that is to be forwarded by the Citizen Card Environment in identical form to the citizen's browser.

As a third option, the application server can forward an XML command to the Citizen Card Environment in the HTTP response; the command is then to be processed there. Three different options are to be distinguished here:

  1. The application simply sends a new XML command. All remaining form fields (form parameters, forwarding parameters, forwarding headers and other form fields) remain unchanged since the last command processed by the Citizen Card Environment .
  2. The application server sends a new XML command as well as a new value for the DataURL form parameter. All remaining form fields remain unchanged since the last command processed by the Citizen Card Environment.
  3. The application server sends a completely new set of form fields (form parameters, forwarding parameters, forwarding headers, other form fields).

Option 2 is used in this example: First the InfoboxAvailable command is transmitted to the Citizen Card Environment using the HTML form. The latter then sends the corresponding XML command response to the DataURL. The application server analyses this response and reacts in different ways, depending on whether an info box named TutorialBinary exists:

In the second case, as a reaction to receiving the XML command response for InfoboxCreate, the application server then sends the InfoboxUpdate XML command as a third command. This second case is shown below.

HTML form

The following HTML form has been generated dynamically by the application and can be loaded from the URL http://localhost:8080/SL12Tutorial/Cascade provided that the web application is installed. Please note that for better readability, it has been formatted and line breaks have been added (indicated by the \ character at the end of a line).

[01] <html>
[02]   <head>
[03]     <title>Kaskadierung: Start</title>
[04]   </head>
[05]   <body>
[06]     <form method="post" action="http://127.0.0.1:3495/http-security-layer-request">
[07]       <input name="XMLRequest" type="hidden" 
[08]         value="<?xml version='1.0' encoding='UTF-8'?><InfoboxAvailableRequest \
[09] xmlns='http://www.buergerkarte.at/namespaces/securitylayer/1.2#'/>" />
[10]       <input name="DataURL" type="hidden" 
[11]         value="http://localhost:8080/SL12Tutorial/Cascade?use=available" />
[12]       <input name="Request absenden" type="submit" />
[13]     </form>
[14]   </body>
[15] </html>
HTTP request from the browser to the Citizen Card Environment

Here you can see the HTTP request that results from the transmission of the form in the HTML page above. Please note that line breaks have been added to it (indicated by the \ character at the end of a line) for better readability.

[01] POST /http-security-layer-request HTTP/1.1
[02] Host: 127.0.0.1
[03] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 \
[04] Firefox/1.0
[05] Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;\
[06] q=0.8,image/png,*/*;q=0.5
[07] Accept-Language: de-at,de;q=0.7,en;q=0.3
[08] Accept-Encoding: gzip,deflate
[09] Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
[10] Keep-Alive: 300
[11] Connection: keep-alive
[12] Referer: http://localhost:8080/SL12Tutorial/Cascade
[13] Content-Type: application/x-www-form-urlencoded
[14] Content-Length: 286
[15] 
[16] XMLRequest=%3C%3Fxml+version%3D%271.0%27+encoding%3D%27UTF-8%27%3F%3E%3CInfobox\
[17] AvailableRequest+xmlns%3D%27http%3A%2F%2Fwww.buergerkarte.at%2Fnamespaces%2Fsec\
[18] uritylayer%2F1.2%23%27%2F%3E&DataURL=http%3A%2F%2Flocalhost%3A8080%2FSL12Tutori\
[19] al%2FCascade%3Fuse%3Davailable&Request+absenden
First HTTP request from the Citizen Card Environment to DataURL

Next you will see the first HTTP request from the Citizen Card Environment to the application behind the DataURL. Among other things, this contains the XML command response for InfoboxAvailable. Please note that line breaks have been added to the HTTP request (indicated by the \ character at the end of a line) for better readability.

[01] POST /SL12Tutorial/Cascade?use=available HTTP/1.1
[02] Referer: localhost
[03] User-Agent: citizen-card-environment/1.2 trustDeskbasic/2.2.3-developer
[04] Content-Type: application/x-www-form-urlencoded
[05] Host: 127.0.0.1
[06] Content-Length: 684
[07] Connection: Keep-Alive

[08] Cache-Control: no-cache
[09] 
[10] XMLResponse=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%0D%0A%3C\
[11] sl%3AInfoboxAvailableResponse+xmlns%3Asl%3D%22http%3A%2F%2Fwww.buergerkarte.at%\
[12] 2Fnamespaces%2Fsecuritylayer%2F1.2%23%22%3E%0D%0A%3Csl%3AInfoboxIdentifier%3ECe\
[13] rtificates%3C%2Fsl%3AInfoboxIdentifier%3E%0D%0A%3Csl%3AInfoboxIdentifier%3EIden\
[14] tityLink%3C%2Fsl%3AInfoboxIdentifier%3E%0D%0A%3Csl%3AInfoboxIdentifier%3ECompre\
[15] ssedIdentityLink%3C%2Fsl%3AInfoboxIdentifier%3E%0D%0A%3Csl%3AInfoboxIdentifier%\
[16] 3EMandates%3C%2Fsl%3AInfoboxIdentifier%3E%0D%0A%3Csl%3AInfoboxIdentifier%3ETuto\
[17] rialAssocArray%3C%2Fsl%3AInfoboxIdentifier%3E%0D%0A%3C%2Fsl%3AInfoboxAvailableR\
[18] esponse%3E&ResponseType=HTTP-Security-Layer-RESPONSE
First HTTP response from DataURL to the Citizen Card Environment

The first HTTP response from the application behind the DataURL to the Citizen Card Environment is shown below. Please note that line breaks have been added to it (indicated by the \ character at the end of a line) for better readability.

[01] HTTP/1.1 307 Temporary Redirect
[02] Location: http://localhost:8080/SL12Tutorial/Cascade?use=update
[03] Content-Type: text/xml
[04] Content-Length: 442
[05] Date: Tue, 28 Dec 2004 09:55:39 GMT
[06] Server: Apache Coyote/1.0
[07] 
[08] <?xml version='1.0' encoding='UTF-8'?>
[09] <sl:InfoboxCreateRequest xmlns:sl='http://www.buergerkarte.at/namespaces/securi\
[10] tylayer/1.2#'>
[11]   <sl:InfoboxIdentifier>TutorialBinary</sl:InfoboxIdentifier>
[12]   <sl:InfoboxType>BinaryFile</sl:InfoboxType>
[13]   <sl:Creator>Tutorium zur Österreichischen Bürgerkarte</sl:Creator>
[14]   <sl:Purpose>Demonstriert das Anlegen, Lesen, Verändern und Löschen einer Bi\
[15] närdatei.</sl:Purpose>
[16] </sl:InfoboxCreateRequest>

Option 2 is used here, i.e. a new XML command (InfoboxCreate) is sent to the Citizen Card Environment.

Thus, an HTTP Redirect (cf. code 307 in line 1) with a text/xml type payload (cf. line 3) is sent.

The new value for the DataURL form parameter is transmitted as a value of the HTTP header Location in line 2.

The new XML command is sent as payload in the HTTP response (cf. lines 8 to 16).

Second HTTP request from the Citizen Card Environment to DataURL

Next you will see the second HTTP request from the Citizen Card Environment to the application behind the DataURL. Among other things, this contains the XML command response for InfoboxCreate. Please note that line breaks have been added to the HTTP request (indicated by the \ character at the end of a line) for better readability.

[01] POST /SL12Tutorial/Cascade?use=update HTTP/1.1
[02] Referer: localhost
[03] User-Agent: citizen-card-environment/1.2 trustDeskbasic/2.2.3-developer
[04] Content-Type: application/x-www-form-urlencoded
[05] Host: localhost:8080
[06] Content-Length: 407
[07] Connection: Keep-Alive
[08] Cache-Control: no-cache
[09] 
[10] XMLResponse=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%0D%0A%3C\
[11] sl%3AInfoboxCreateResponse+xmlns%3Asl%3D%22http%3A%2F%2Fwww.buergerkarte.at%2Fn\
[12] amespaces%2Fsecuritylayer%2F1.2%23%22%2F%3E&ResponseType=HTTP-Security-Layer-RE\
[13] SPONSE
Second HTTP response from DataURL to the Citizen Card Environment

The second HTTP response from the application behind the DataURL to the Citizen Card Environment is shown below. Please note that line breaks have been added to it (indicated by the \ character at the end of a line) for better readability.

[01] HTTP/1.1 307 Temporary Redirect
[02] Location: http://localhost:8080/SL12Tutorial/Cascade?use=done
[03] Content-Type: text/xml
[04] Content-Length: 491
[05] Date: Tue, 28 Dec 2004 09:55:42 GMT
[06] Server: Apache Coyote/1.0
[07] 
[08] <?xml version='1.0' encoding='UTF-8'?>
[09] <sl:InfoboxUpdateRequest xmlns:sl='http://www.buergerkarte.at/namespaces/securi\
[10] tylayer/1.2#'>
[11]   <sl:InfoboxIdentifier>TutorialBinary</sl:InfoboxIdentifier>
[12]   <sl:BinaryFileParameters>
[13]     <sl:XMLContent>
[14]       <my:Customer xmlns:my='urn:my.namespace'>
[15]         <my:Name>Tassilo Tester</my:Name>
[16]         <my:LastVisit>2005-01-01</my:LastVisit>
[17]       </my:Customer>
[18]     </sl:XMLContent>
[19]   </sl:BinaryFileParameters>
[20] </sl:InfoboxUpdateRequest>

Again, option 2 is used here, so that the latest new XML command (InfoboxUpdate) is sent to the Citizen Card Environment (see the first response).

Third HTTP request from the Citizen Card Environment to DataURL

Next you will see the third HTTP request from the Citizen Card Environment to the application behind the DataURL. Among other things, this contains the XML command response for InfoboxUpdate. Please note that line breaks have been added to the HTTP request (indicated by the \ character at the end of a line) for better readability.

[01] POST /SL12Tutorial/Cascade?use=done HTTP/1.1
[02] Referer: localhost
[03] User-Agent: citizen-card-environment/1.2 trustDeskbasic/2.2.3-developer
[04] Content-Type: application/x-www-form-urlencoded
[05] Host: localhost:8080
[06] Content-Length: 240
[07] Connection: Keep-Alive
[08] Cache-Control: no-cache
[09] 
[10] XMLResponse=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%0D%0A%3C\
[11] sl%3AInfoboxUpdateResponse+xmlns%3Asl%3D%22http%3A%2F%2Fwww.buergerkarte.at%2Fn\
[12] amespaces%2Fsecuritylayer%2F1.2%23%22%3E&ResponseType=HTTP-Security-Layer-RESPO\
[13] NSE
Third HTTP response from DataURL to the Citizen Card Environment

The third HTTP response from the application behind the DataURL to the Citizen Card Environment is shown below. Please note that line breaks have been added to it (indicated by the \ character at the end of a line) for better readability.

[01] HTTP/1.1 200 OK
[02] Content-Type: text/html
[03] Content-Length: 205
[04] Date: Tue, 28 Dec 2004 09:56:08 GMT
[05] Server: Apache Coyote/1.0
[06] 
[07] <html>
[08] <head><title>Kaskadierung: Abschluss</title></head>
[09] <body>
[10] <p>Infobox <code style='background-color: silver;'>TutorialBinary</code> \
[11] ist angelegt und auf dem letzten Stand.</p>
[12] </body>
[13] </html>

Similarly to the previous examples, the application concludes by transmitting an HTML document, which is to be forwarded by the Citizen Card Environment in identical form to the citizen's browser (cf. lines 7 to 13).

HTTP response from the Citizen Card Environment to the browser

Finally below, you will also find the HTTP response from the Citizen Card Environment to the citizen's browser. Please note that line breaks have been added to it (indicated by the \ character at the end of a line) for better readability.

[01] HTTP/1.1 200 OK
[02] Content-Type: text/html
[03] Content-Length: 205
[04] Date: Tue, 28 Dec 2004 09:56:08 GMT
[05] Server: Apache Coyote/1.0
[06] 
[07] <html>
[08] <head><title>Kaskadierung: Abschluss</title></head>
[09] <body>
[10] <p>Infobox <code style='background-color: silver;'>TutorialBinary</code> \
[11] ist angelegt und auf dem letzten Stand.</p>
[12] </body>
[13] </html>
Downloads for this example
Further information

3.2.3 Typical application scenarios

This section builds on sections 3.2.1 and 3.2.2, providing further examples of how to transmit XML commands via HTTP and HTTPS as transport protocols. It contains specific solutions for questions that frequently arise in practice.

3.2.3.1 Transmitting a person identity link and signing a document (Sign On)

This example presents a solution for a frequently required combination involving the reading out the IdentityLink (person identity link) info box and the subsequent signing of a document by the citizen.

The basic procedure is the same as in example 3.2.2.4:

  1. The citizen's browser uses an HTML form to transmit the XML command InfoboxRead for reading out the person identity link to the Citizen Card Environment.
  2. The Citizen Card Environment transmits the XML command response for InfoboxRead to the application behind the DataURL.
  3. The application responds with a new XML command CreateXMLSignature to the Citizen Card Environment.
  4. The Citizen Card Environment transmits the XML command response for CreateXMLSignature to the application behind the DataURL.
  5. The application responds with an HTML document.
  6. The Citizen Card Environment forwards this HTML document to the citizen's browser.
HTML form

The following HTML form has been generated dynamically by the application and can be loaded from the URL http://localhost:8080/SL12Tutorial/SignOn provided that the web application is installed. Please note that for better readability, it has been formatted and line breaks have been added (indicated by the \ character at the end of a line).

[01] <html>
[02]   <head>
[03]     <title>Sign On: Start</title>
[04]   </head>
[05]   <body>
[06]     <form method="post" action="http://127.0.0.1:3495/http-security-layer-request">
[07]       <input name="XMLRequest" type="hidden" 
[08]         value="<?xml version='1.0' encoding='UTF-8'?><InfoboxReadRequest \
[09] xmlns='http://www.buergerkarte.at/namespaces/securitylayer/1.2#'><InfoboxIdentifier>\
[10] IdentityLink</InfoboxIdentifier><BinaryFileParameters ContentIsXMLEntity='true'/>\
[11] </InfoboxReadRequest>" />
[12]       <input name="DataURL" type="hidden" 
[13]         value="https://localhost:8443/SL12Tutorial/SignOn;\
[14] jsessionid=B498616CC781C4BA5B0B4BE03CAA523A?use=sign" />
[15]       <input name="Request absenden" type="submit" />
[16]     </form>
[17]   </body>
[18] </html>

Form parameter XMLRequest is encoded with the XML command request in lines 7 to 11.

The DataURL form parameter is encoded in lines 12 to 14. Please note that in this case, an https URL is used. This is necessary because the Citizen Card Environment may only send the person identity link to a destination that can be identified by means of an SSL server certificate and verified as being assigned to a public authority (either because the domain name of the SSL server certificate ends in .gv.at or because the SSL server certificate contains the certificate extension administrative property).

Note: If you want to use this example in the private sector, you must change the command for reading out the person identity link in such a way that the Citizen Card Environment hides the sourcePIN in the person identity link (see section 2.7.4.1.2). The Citizen Card Environment may then also send the person identity link to a destination identified by means of a SSL server certificate that cannot be verified as being assigned to a public authority.

Note: To try out this example using the web application supplied with this tutorial, you must use an SSL server certificate that meets the above requirements for the web application. For test purposes, this can be a certificate you have issued yourself, however you must also configure this as a trustworthy certificate in the Citizen Card Environment.

HTTP request from the browser to the Citizen Card Environment

Here you can see the HTTP request that results from sending the form in the HTML page above. Please note that line breaks have been added to it (indicated by the \ character at the end of a line) for better readability.

[01] POST /http-security-layer-request HTTP/1.1
[02] Host: 127.0.0.1
[03] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 \
[04] Firefox/1.0
[05] Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;\
[06] q=0.8,image/png,*/*;q=0.5
[07] Accept-Language: de-at,de;q=0.7,en;q=0.3
[08] Accept-Encoding: gzip,deflate
[09] Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
[10] Keep-Alive: 300
[11] Connection: keep-alive
[12] Content-Type: application/x-www-form-urlencoded
[13] Content-Length: 469
[14] 
[05] XMLRequest=%3C%3Fxml+version%3D%271.0%27+encoding%3D%27UTF-8%27%3F%3E%3CInfobox\
[16] ReadRequest+xmlns%3D%27http%3A%2F%2Fwww.buergerkarte.at%2Fnamespaces%2Fsecurity\
[17] layer%2F1.2%23%27%3E%3CInfoboxIdentifier%3EIdentityLink%3C%2FInfoboxIdentifier%\
[18] 3E%3CBinaryFileParameters+ContentIsXMLEntity%3D%27true%27%2F%3E%3C%2FInfoboxRea\
[19] dRequest%3E&DataURL=https%3A%2F%2Flocalhost%3A8443%2FSL12Tutorial%2FSignOn%3Bjs\
[20] essionid%3DB498616CC781C4BA5B0B4BE03CAA523A%3Fuse%3Dsign&Request+absenden
First HTTP request from the Citizen Card Environment to DataURL

The HTTP connection for forwarding the person identity link to the application behind the DataURL is encrypted with TLS. For this reason, the HTTP request cannot be shown here.

It contains the XML response to the InfoboxRead command with the read-out person identity link and otherwise has largely the same structure as the first HTTP request of the Citizen Card Environment from example 3.2.2.4.

First HTTP response from the Citizen Card Environment to DataURL

The HTTP connection for forwarding the person identity link to the application behind the DataURL is encrypted with TLS. For this reason, the HTTP response cannot be shown here.

It contains the XML command CreateXMLSignature for signing a short HTML document (sign-on token for a Sign On) and otherwise has largely the same structure as the first HTTP response from the Citizen Card Environment from example 3.2.2.4.

Second HTTP request from the Citizen Card Environment to DataURL

Below you will see the second HTTP request from the Citizen Card Environment to the application behind the DataURL. Among other things, this contains the XML command response for CreateXMLSignature. Please note that, for better readability, the HTTP request has been shortened (indicated by ...) and line breaks have been added (indicated by the \ character at the end of a line).

[01] POST /SL12Tutorial/SignOn;jsessionid=B498616CC781C4BA5B0B4BE03CAA523A?use=done HTTP/1.1
[02] Referer: localhost
[03] User-Agent: citizen-card-environment/1.2 trustDeskbasic/2.2.3-developer
[04] Content-Type: application/x-www-form-urlencoded
[05] Host: 127.0.0.1
[06] Content-Length: 6209
[07] Connection: Keep-Alive
[08] Cache-Control: no-cache
[09] 
[10] XMLResponse=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%3Csl11%3\
[11] ACreateXMLSignatureResponse+xmlns%3Asl11%3D%22http%3A%2F%2Fwww.buergerkarte.at%\
[12] ...
[13] dsig%3ASignature%3E%3C%2Fsl11%3ACreateXMLSignatureResponse%3E&ResponseType=HTTP\
[14] -Security-Layer-RESPONSE
Third HTTP response from DataURL to the Citizen Card Environment

The third HTTP response from the application behind the DataURL to the Citizen Card Environment is shown below. Please note that line breaks have been added to it (indicated by the \ character at the end of a line) for better readability.

[01] HTTP/1.1 200 OK
[02] Content-Type: text/html
[03] Transfer-Encoding: chunked
[04] Date: Tue, 28 Dec 2004 12:30:18 GMT
[05] Server: Apache Coyote/1.0
[06] 
[07] 2000
[08] <html>
[09] <head>
[10] <title>Sign On: Abschluss</title>
[11] <meta http-equiv="content-type" content="text/html; charset=UTF-8">
[02] <head>
[13] <body>
[14] <p>Folgende Personenbindung wurde gelesen:</p>
[15] <pre style="background-color: silver;"><?xml version="1.0" encoding="UTF-8"?>
[16] <saml:Assertion AssertionID="szr.bmi.gv.at-AssertionID1086963510976445" \
[17] ...
[18] /dsig:Signature></saml:Assertion></pre><p>Folgende Signatur ist eingelangt:</p>
[19] <pre style="background-color: silver;"><?xml version="1.0" encoding="UTF-8"?>
[20] <dsig:Signature Id="signature-28122004132954494" \
[21] ...
[22] </dsig:Signature></pre></body>
[23] </html>

Similarly to the previous examples, the application concludes by sending an HTML document, which is to be forwarded by the Citizen Card Environment in identical form to the citizen's browser (cf. lines 8 to 23).

HTTP response from the Citizen Card Environment to the browser

Finally below, you will also find the HTTP response from the Citizen Card Environment to the citizen's browser. Please note that line breaks have been added to it (indicated by the \ character at the end of a line) for better readability.

[01] HTTP/1.1 200 OK
[02] Content-Type: text/html
[03] Transfer-Encoding: chunked
[04] Date: Tue, 28 Dec 2004 12:30:18 GMT
[05] Server: Apache Coyote/1.0
[06] 
[07] 2000
[08] <html>
[09] <head>
[10] <title>Sign On: Abschluss</title>
[11] <meta http-equiv="content-type" content="text/html; charset=UTF-8">
[02] <head>
[13] <body>
[14] <p>Folgende Personenbindung wurde gelesen:</p>
[15] <pre style="background-color: silver;"><?xml version="1.0" encoding="UTF-8"?>
[16] <saml:Assertion AssertionID="szr.bmi.gv.at-AssertionID1086963510976445" \
[17] ...
[18] /dsig:Signature></saml:Assertion></pre><p>Folgende Signatur ist eingelangt:</p>
[19] <pre style="background-color: silver;"><?xml version="1.0" encoding="UTF-8"?>
[20] <dsig:Signature Id="signature-28122004132954494" \
[21] ...
[22] </dsig:Signature></pre></body>
[23] </html>
Downloads for this example
Further information

3.2.3.2 Signing an application with annexes

This example shows a solution for the frequent scenario in which the citizen needs to upload annexes to the application and subsequently sign them together with a completed request.

Since annexes (e.g. CAD drawings, PDF documents, etc.) are mostly in formats that cannot be signed using the secure signature, you are advised to choose the alternative option and not to sign the annexes directly, but only a hash value calculated for them.

The question arises, however, of who is to calculate this hash value. One option would be to have the calculation performed by the application However, this could lead to acceptance problems with citizens because they would not know whether the hash values calculated by the application and suggested for signature actually match the annexes uploaded by the citizens.

For this reason, it makes more sense to have the hash value calculated by the Citizen Card Environment using the CreateHash command.

The basic procedure is again the same as in example 3.2.3.1:

  1. The citizen's browser uses an HTML form to transmit the XML command CreateHash for calculating the hash value for an annex to the Citizen Card Environment. The annex itself is forwarded as a forwarding parameter together with the XML command.
  2. The Citizen Card Environment informs the citizen that a hash value is to be created. The citizen can view or save the document for which the hash value is to be calculated. The Citizen Card Environment also maintains the calculated hash value for subsequent verification by the citizen. If the citizen gives the OK, it transmits the XML command response for CreateHash to the application behind the DataURL.
  3. The application reads the XML command response containing the calculated hash value and the annex itself, which was forwarded as a forwarding parameter by the Citizen Card Environment together with the XML command response. The application then responds with a new XML command CreateXMLSignature to the Citizen Card Environment. Part of the data to be signed with this command is the hash value for the uploaded annex. When the citizen views the document to be signed with the included hash value in the viewer component of the Citizen Card Environment, he can use a separate function in the user interface of the Citizen Card Environment to compare this hash value with the hash value previously calculated by the Citizen Card Environment. If the hash values match, he can be sure that he is signing the correct hash value.
  4. The Citizen Card Environment transmits the XML command response for CreateXMLSignature to the application behind the DataURL.
  5. The application responds with an HTML document.
  6. The Citizen Card Environment forwards this HTML document to the citizen's browser.
HTML form

The following HTML form has been generated dynamically by the application and can be loaded from the URL http://localhost:8080/SL12Tutorial/SignAttachments provided that the web application is installed. Please note that for better readability, it has been formatted and line breaks have been added (indicated by the \ character at the end of a line).

[01] <?xml version='1.0' encoding='UTF-8'?>
[02] <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/\
[03] xhtml1/DTD/xhtml1-strict.dtd">
[04] <html xmlns='http://www.w3.org/1999/xhtml'>
[05] 	<head>
[06] 		<title>Signieren von Beilagen: Start</title>
[07] 	</head>
[08] 	<body>
[09] 		<p>Bitte füllen Sie das folgende Formular 0815 aus:</p>
[10] 		<form style='background-color: silver;' 
[11] 		  action='http://127.0.0.1:13495/http-security-layer-request' method='post' 
[12] 		  enctype='multipart/form-data' name='form1' id='form1'>
[13] 		  <p><code>Vorname: </code><input name='Vorname_' type='text' id='vorname_'/><br/>
[14] 		  <code>Nachname:</code><input name='Nachname_' type='text' id='nachname_'/></p>	
[15] 		  <p><code>Beilage:</code><input type='file' name='Beilage_'/></p>
[16] 		  <p><input type='submit' value='Weiter ...'/></p>
[17] 		  <input type='hidden' name='XMLRequest' 
[18] 		    value='<?xml version="1.0" encoding="UTF-8"?><sl:CreateHashReques\
[19] t xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">  <sl:\
[20] HashInfo RespondHashData="false">    <sl:HashData>      <sl:MetaInfo>    \
[21]     <sl:MimeType>application/octet-stream</sl:MimeType>      </sl:Meta\
[22] Info>      <sl:Content Reference="formdata:Beilage_"/>    </sl:HashData> \
[23]    <sl:HashAlgorithm>http://www.w3.org/2000/09/xmldsig#sha1</sl:HashAlgor\
[24] ithm>    <sl:FriendlyName>Beilage zum Formular 0815</sl:FriendlyName>  &l\
[25] t;/sl:HashInfo></sl:CreateHashRequest>'/>
[26]      <input name='DataURL' type='hidden' 
[27]        value='http://localhost:18080/SL12Tutorial/SignAttachments;jsessionid=2B\
[28] AF01A9069F6AF073A25B4D9B8E803E?use=sign'/>	    </form>
[29] 		<p>  </p>
[30] 	</body>
[31] </html>

The two forwarding parameters Vorname_ and Nachname_ are encoded in lines 13 and 14. They represent the actual request.

The forwarding parameter Beilage_ is encoded in line 15. The type="file" attribute indicates that a file is to be uploaded.

The XML command is encoded as XMLRequest form parameter in lines 17 to 25. Please note how the sl:Content/@Reference attribute in line 22 in this command uses the formdata:Beilage_ URL to reference the content of the forwarding parameter containing the annex to be uploaded.

HTTP request from the browser to the Citizen Card Environment

Here you can see the HTTP request that results from the transmission of the form in the HTML page above. Please note that line breaks have been added to it (indicated by the \ character at the end of a line) for better readability.

[01] POST /http-security-layer-request HTTP/1.1
[02] Host: 127.0.0.1
[03] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 \
[04] Firefox/1.0
[05] Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;\
[06] q=0.8,image/png,*/*;q=0.5
[07] Accept-Language: de-at,de;q=0.7,en;q=0.3
[08] Accept-Encoding: gzip,deflate
[09] Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
[10] Keep-Alive: 300
[11] Connection: keep-alive
[12] Content-Type: multipart/form-data; boundary=---------------------------2330864292941
[13] Content-Length: 1800
[14] 
[15] -----------------------------2330864292941
[16] Content-Disposition: form-data; name="Vorname_"
[17] 
[18] Thassilo
[19] -----------------------------2330864292941
[20] Content-Disposition: form-data; name="Nachname_"
[21] 
[22] Tester
[23] -----------------------------2330864292941
[24] Content-Disposition: form-data; name="Beilage_"; filename="Beilage.png"
[25] Content-Type: image/png
[26] 
[27] ...
[28] -----------------------------2330864292941
[29] Content-Disposition: form-data; name="XMLRequest"
[30] 
[31] <?xml version="1.0" encoding="UTF-8"?><sl:CreateHashRequest \
[32] xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">  \
[33] <sl:HashInfo RespondHashData="false">    <sl:HashData>      <sl:MetaInfo>        \
[34] <sl:MimeType>application/octet-stream</sl:MimeType>      </sl:MetaInfo>      \
[35] <sl:Content Reference="http://www.buergerkarte.at/konzept/securitylayer/\
[36] spezifikation/20040514/tutorial/examples/bindings/signattachments/Beilage.png"/>    \
[37] </sl:HashData>    <sl:HashAlgorithm>http://www.w3.org/2000/09/xmldsig#sha1\
[38] </sl:HashAlgorithm>    <sl:FriendlyName>Beilage zum Formular 0815</sl:FriendlyName>  \
[39] </sl:HashInfo></sl:CreateHashRequest>
[40] -----------------------------2330864292941
[41] Content-Disposition: form-data; name="DataURL"
[42] 
[43] http://localhost:18080/SL12Tutorial/SignAttachments;jsessionid=2BAF01A9069F6AF0\
[44] 73A25B4D9B8E803E?use=sign
[45] -----------------------------2330864292941--

Since the form contained a file type input element, the browser selects multipart/form-data for the encoding of the form elements (cf. line 12).

The payload contains the forwarding parameters in the following sequence: Vorname_ (lines 16 to 18), Nachname_ (lines 20 to 22), Beilage_ (a png image, lines 24 to 27), the XMLRequest form parameter (CreateHash, lines 29 to 39), and the DataURL form parameter (lines 41 to 44).

First HTTP request from the Citizen Card Environment to DataURL

Next you will see the first HTTP request from the Citizen Card Environment to the application behind the DataURL. Among other things, this contains the XML command response for CreateHash and the forwarding parameters mentioned above (Vorname_, Nachname_ and Beilage_). Please note that line breaks have been added to the HTTP request (indicated by the \ character at the end of a line) for better readability.

[01] POST /SL12Tutorial/SignAttachments;jsessionid=2BAF01A9069F6AF073A25B4D9B8E803E?use=sign HTTP/1.1
[02] Referer: localhost
[03] User-Agent: citizen-card-environment/1.2 trustDeskbasic/2.2.3-developer
[04] Content-Type: multipart/form-data; boundary=---------------------------0505ccc0949c35
[05] Host: 127.0.0.1
[06] Content-Length: 1469
[07] Connection: Keep-Alive
[08] Cache-Control: no-cache
[09] 
[00] -----------------------------0505ccc0949c35
[01] Content-Disposition: form-data; name="ResponseType"
[02] 
[03] HTTP-Security-Layer-RESPONSE
[04] -----------------------------0505ccc0949c35
[05] Content-Disposition: form-data; name="XMLResponse"
[06] 
[07] <?xml version="1.0" encoding="UTF-8"?><sl:CreateHashResponse \
[08] xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#"><sl:HashInfo>\
[09] <sl:HashAlgorithm>http://www.w3.org/2000/09/xmldsig#sha1</sl:HashAlgorithm>\
[00] <sl:FriendlyName>Beilage zum Formular 0815</sl:FriendlyName>\
[01] <sl:HashValue>ijB9/RGrjhilvBXCB5YWGSVusoI=</sl:HashValue></sl:HashInfo>\
[02] </sl:CreateHashResponse>
[03] -----------------------------0505ccc0949c35
[04] Content-Disposition: form-data; name="Vorname_"
[05] 
[06] Thassilo
[07] -----------------------------0505ccc0949c35
[08] Content-Disposition: form-data; name="Nachname_"
[09] 
[00] Tester
[01] -----------------------------0505ccc0949c35
[02] Content-Disposition: form-data; name="Beilage_"; filename="Beilage.png" 
[03] Content-Type: image/png
[04] 
[05] ...
[06] -----------------------------0505ccc0949c35--
First HTTP response from DataURL to the Citizen Card Environment

The first HTTP response from the application behind the DataURL to the Citizen Card Environment is shown below. Please note that line breaks have been added to it (indicated by the \ character at the end of a line) for better readability.

[01] HTTP/1.1 307 Temporary Redirect
[02] Location: http://localhost:8080/SL12Tutorial/SignAttachments;\
[03] jsessionid=2BAF01A9069F6AF073A25B4D9B8E803E?use=done
[04] Content-Type: text/xml
[05] Content-Length: 996
[06] Date: Tue, 28 Dec 2004 16:49:00 GMT
[07] Server: Apache Coyote/1.0
[08] 
[09] <?xml version='1.0' encoding='UTF-8'?>
[10] <sl:CreateXMLSignatureRequest \
[11] xmlns:sl='http://www.buergerkarte.at/namespaces/securitylayer/1.2#'>
[12]   <sl:KeyboxIdentifier>SecureSignatureKeypair</sl:KeyboxIdentifier>
[13]   <sl:DataObjectInfo Structure='enveloping'>
[14]     <sl:DataObject>
[15]       <sl:XMLContent><html xmlns='http://www.w3.org/1999/xhtml'>
[16] 	<head>
[17] 		<title>Formular 0815</title>
[18] 		<style type='text/css'>.silver{ background-color: silver;}</style>
[19] 	</head>
[20] 	<body>
[21] 		<h3>Formular 0815</h3>
[22] 		<p>Vorname: <code class='silver'>Thassilo</code></p>
[23] 		<p>Nachname: <code class='silver'>Tester</code></p>
[24] 		<h3>Beilage zu Formular 0815</h3>
[25] 		<p>Prüfsumme (SHA-1, base64-kodiert): \
[26] <code class='silver'>ijB9/RGrjhilvBXCB5YWGSVusoI=</code></p>
[27] 	</body>
[28] </html>
[29] </sl:XMLContent>
[30]     </sl:DataObject>
[31]     <sl:TransformsInfo>
[32]       <sl:FinalDataMetaInfo>
[33]         <sl:MimeType>text/html</sl:MimeType>
[34]       </sl:FinalDataMetaInfo>
[35]     </sl:TransformsInfo>
[36]   </sl:DataObjectInfo>
[37] </sl:CreateXMLSignatureRequest>

The payload (cf. lines 9 to 37) contains the next command to the Citizen Card Environment (CreateXMLSignature).

Lines 15 to 28 show the document to be signed by the citizen. It is apparent that the hash value previously calculated by the Citizen Card Environment is also contained there (lines 25 and 26).

Second HTTP request from the Citizen Card Environment to DataURL

Next you will see the second HTTP request from the Citizen Card Environment to the application behind the DataURL. Among other things, this contains the XML command response for CreateXMLSignature. Please note that, for better readability, the HTTP request has been shortened (indicated by ...) and line breaks have been added (indicated by the \ character at the end of a line).

[01] POST /SL12Tutorial/SignAttachments;jsessionid=2BAF01A9069F6AF073A25B4D9B8E803E?use=done HTTP/1.1
[02] Referer: localhost
[03] User-Agent: citizen-card-environment/1.2 trustDeskbasic/2.2.3-developer
[04] Content-Type: multipart/form-data; boundary=---------------------------04a36030005bad
[05] Host: localhost:18080
[06] Content-Length: 6602
[07] Connection: Keep-Alive
[08] Cache-Control: no-cache
[09] 
[10] -----------------------------04a36030005bad
[11] Content-Disposition: form-data; name="ResponseType"
[12] 
[13] HTTP-Security-Layer-RESPONSE
[14] -----------------------------04a36030005bad
[15] Content-Disposition: form-data; name="XMLResponse"
[16] 
[17] <?xml version="1.0" encoding="UTF-8"?><sl11:CreateXMLSignatureResponse \
[18] xmlns:sl11="http://www.buergerkarte.at/namespaces/securitylayer/20020831#">\
[19] ...
[20] </dsig:Signature></sl11:CreateXMLSignatureResponse>
[21] -----------------------------04a36030005bad
[22] Content-Disposition: form-data; name="Vorname_"
[23] 
[24] Thassilo
[25] -----------------------------04a36030005bad
[26] Content-Disposition: form-data; name="Nachname_"
[27] 
[28] Tester
[29] -----------------------------04a36030005bad
[30] Content-Disposition: form-data; name="Beilage_"; filename="Beilage.png" 
[31] Content-Type: image/png
[32] 
[33] ...
[34] -----------------------------04a36030005bad--
Second HTTP response from DataURL to the Citizen Card Environment

The second HTTP response from the application behind the DataURL to the Citizen Card Environment is shown below. Please note that for better readability, it has been shortened (indicated by ...) and line breaks have been added (indicated by the \ character at the end of a line).

[01] HTTP/1.1 200 OK
[02] Content-Type: text/html
[03] Content-Length: 5919
[04] Date: Tue, 28 Dec 2004 16:49:51 GMT
[05] Server: Apache Coyote/1.0
[06] 
[07] <html>
[08] <head>
[09] <title>Signieren von Beilagen: Abschluss</title>
[10] <meta http-equiv="content-type" content="text/html; charset=UTF-8">
[11] <head>
[12] <body>
[13] <p>Folgende Signatur ist eingelangt:</p>
[14] <pre style="background-color: silver;"><?xml version="1.0" encoding="UTF-8"?>
[15] <dsig:Signature Id="signature-28122004174904293" \
[16] xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">\
[17] ...
[18] </dsig:Signature></pre></body>
[19] </html>

Similarly to the previous examples, the application concludes by transmitting an HTML document, which is to be forwarded by the Citizen Card Environment in identical form to the citizen's browser (cf. lines 8 to 23).

HTTP response from the Citizen Card Environment to the browser

Finally below, you will also find the HTTP response from the Citizen Card Environment to the citizen's browser. Please note that line breaks have been added to it (indicated by the \ character at the end of a line) for better readability.

[01] HTTP/1.1 200 OK
[02] Content-Type: text/html
[03] Content-Length: 5919
[04] Date: Tue, 28 Dec 2004 16:49:51 GMT
[05] Server: Apache Coyote/1.0
[06] 
[07] <html>
[08] <head>
[09] <title>Signieren von Beilagen: Abschluss</title>
[10] <meta http-equiv="content-type" content="text/html; charset=UTF-8">
[11] <head>
[12] <body>
[13] <p>Folgende Signatur ist eingelangt:</p>
[14] <pre style="background-color: silver;"><?xml version="1.0" encoding="UTF-8"?>
[15] <dsig:Signature Id="signature-28122004174904293" \
[16] xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">\
[17] ...
[18] </dsig:Signature></pre></body>
[19] </html>
Downloads for this example
Further information

4 Standardised viewer format SLXHTML

One of the key aspects when creating applications that use the signature commands of the Citizen Card is the selection of a suitable format for the data to be signed, so that it can be displayed in the viewer component of the Citizen Card Environment and subsequently signed.

To begin with, a Citizen Card Environment can display and sign text documents (including mime types text/plain, text/xml and application/xml). Since this format is largely self-explanatory, it will not be explained further here.

As a further format a Citizen Card Environment accepts documents in SLXHTML format (Security Layer XHTML, mime type application/xhtml+xml), the Citizen Card's standardised viewer format. This is a variant of XHTML 1.0; there are certain restrictions in comparison with the initial format so that the format is suitable for displaying data to be signed in the Citizen Card Environment:

In addition, SLXHTML requires a strict separation of structure (with HTML tags) and formatting (with CSS 2) Thus, for example, formatting with old HTML elements such as font, u or center is just as prohibited as the formatting of tables using attributes such as align or valign in the table elements table, td and tr. Instead, suitable constructs from CSS 2 are to be used.

You will find detailed information in the following subsections.

4.1 Initial example

The following is a first minimal document in SLXHTML format. The various explanations contain important information about the fundamental principles of the document structure.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <html xmlns="http://www.w3.org/1999/xhtml">
[03]   <head>
[04]     <title>Ein einfaches SLXHTML-Dokument</title>
[05]     <style type="text/css">p { color: red; }</style>
[06]   </head>
[07]   <body>
[08]     <p>Ich bin ein einfacher Text in rot.</p>
[09]   </body>
[10] </html>

SLXHTML is basically an XML dialect. Thus, in syntax terms, the document must be well-formed XML. This means that opening tags without corresponding closing tags (such as <p> or <br>) are not permitted. Furthermore, the document should always begin with an XML declaration that defines the character set for the document with the encoding attribute (cf. line 1)

All HTML language elements must be contained in the name space http://www.w3.org/1999/xhtml. It is best to use the default name space for this (cf. line 2).

The head element (lines 3 to 6) must be specified. Its content must consist of precisely one title element (line 4), followed by precisely one style element (line 5). The style/@type attribute is fixed at the value text/css, which means that it may only contain CSS formatting information. If no formatting information is provided, then an empty style element is to be specified.

Downloads for this example
Further information

4.2 Comprehensive example

The following is a complex document in SLXHTML format. On the one hand, it demonstrates the available set of HTML language elements and, on the other, the formatting options with constructs from CSS 2.

[001] <?xml version="1.0" encoding="UTF-8"?>
[002] <html xmlns="http://www.w3.org/1999/xhtml">
[003]   <head>
[004]     <title>Ein umfangreiches SLXHTML-Dokument</title>
[005]     <style type="text/css">

The document begins in the same way as the previous simple example. The CSS 2 formatting instructions appear from line 5 onwards.

[006]     body
[007]     {
[008]       font-family: serif;
[009]       font-size: medium;
[010]     }  

The basic properties of text in the document are defined for body. A font with serifs is selected and the font size is defined as medium.

[011]     h1
[012]     {
[013]       font-family: sans-serif;
[014]       font-size: 147%;
[015]       color: #000099;
[016]       margin-top: 0.5em;
[017]       margin-bottom: 0.5em;
[018]     } 
[019]     h2
[020]     {
[021]       font-family: sans-serif;
[022]       font-size: 136%;
[023]       color: #000099;
[024]       margin-top: 0.5em;
[025]       margin-bottom: 0.5em;
[026]     } 
[027]     h3
[028]     {
[029]       font-family: sans-serif;
[030]       font-size: 126%;
[031]       color: #000099;
[032]       margin-top: 0.5em;
[033]       margin-bottom: 0.5em;
[034]     } 
[035]     h4
[036]     {
[037]       font-family: sans-serif;
[038]       font-size: 117%;
[039]       color: #000099;
[040]       margin-top: 0.5em;
[041]       margin-bottom: 0.5em;
[042]     } 
[043]     h5
[044]     {
[045]       font-family: sans-serif;
[046]       font-size: 108%;
[047]       color: #000099;
[048]       margin-top: 0.5em;
[049]       margin-bottom: 0.5em;
[050]     } 
[051]     h6
[052]     {
[053]       font-family: sans-serif;
[054]       font-size: 100%;
[055]       color: #000099;
[056]       margin-top: 0.5em;
[057]       margin-bottom: 0.5em;
[058]     } 

You can see the 6 heading levels here. A sans serif font is selected for each heading (as in line 53), the font size is reduced accordingly (as in lines 54 and 56), the top and bottom margins are defined with a value relative to the font size (0.5em, in other words half the width of the character m, cf. lines 56 and 57, for example), and a blue value is selected as the font colour throughout (as in line 55) .

[059]     p
[060]     {
[061]       text-align: justify;
[062]     }

The paragraph format is defined as justified.

[063]     code
[064]     {
[065]       color: blue;
[066]       font-family: monospace;
[067]       font-size: 90%;
[068]     }

A font with a fixed character width and a blue font are selected for text within the code element. In addition, the font size is reduced a little in relation to the surrounding text.

[069]     em
[070]     {
[071]       font-style: italic;
[072]       color: #990000;
[073]     }

Emphasised text is set in italics with a reddish brown colour.

[074]     strong
[075]     {
[076]       font-weight: bold;
[077]       color: #006633;
[078]     }

Heavily emphasised text appears in bold face in a moss green colour.

[089]     pre
[080]     {
[081]       background-color: #CCCCFF;
[082]     }

Preformatted text appears against a turquoise background.

[083]     blockquote
[084]     {
[085]       font-style: italic;
[086]     }

Long quotes are set in italics.

[087]     table.simple
[088]     {
[089]       background-color: #CCFFCC;
[090]       border-style: dotted;
[091]       border-width: 1px;
[092]       border-color: black;
[093]       margin: 10px;
[094]     }
[095]     caption.simple
[096]     {
[097]       color: #0066FF;
[098]     }

The document contains two tables. The format commands above apply to the first table, because the table and caption elements there have a class="simple" attribute (cf. lines 193 and 194).

The table itself is given a turquoise background colour and a dotted black border with a width of one pixel. The margins on all sides are defined at 10 pixels.

The title of the table is set in a blue font.

[099]     table.extended
[100]     {
[101]       background-color: #FFCC66;
[102]       border-style: solid;
[103]       border-width: 2px;
[104]       border-color: black;
[105]       margin: 20px;
[106]     }

The document contains two tables. The format commands above apply to the second table, because the table element there has a class="extended" attribute (cf. line 214).

The table itself is given a light orange background colour and a solid black border with a width of two pixels. The margins on all sides are defined at 20 pixels.

[107]     thead, tfoot
[108]     {
[109]       background-color: #FF9900;
[110]       padding: 5px;
[111]     }    

A padding of 5 pixels and a dark orange background colour are selected for the header and footer of a table.

[112]     td, th
[113]     {
[114]       padding: 5px;
[115]       border-style: solid;
[116]       border-width: 1px;
[117]       border-color: black;
[118]       }
[119]     td#missing1, td#missing2
[120]     {
[121]       background-color: red;
[122]     }      

A padding of 5 pixels and a solid black border with a width of one pixel are defined for table cells (td, th).

A red background colour is selected for table cells that have an ID attribute with the value missing1 or missing2.

[123]     img
[124]     {
[125]       margin: 20px;
[126]       border-style: solid;
[127]       border-color: black;
[128]       border-width: 1px;

[129]     }  

A margin of 20 pixels on all sides is defined for images. In addition, the images are to be surrounded by a solid black border with a width of one pixel.

[130]     p.img
[131]     {
[132]       text-align: center;
[133]     }  

Images are to be centred in the document. This can be achieved by positioning the image within a separate paragraph and assigning the value center to the CSS property text-align for this paragraph (cf. also line 250).

[134]     ol.level2
[135]     {
[136]       list-style-type: lower-alpha;
[137]     }
[138]       ul.level2
[149]     {
[140]       list-style-type: square;
[141]     }    

Lowercase letters are to be used as list symbols for the second level of a numbered list (cf. line 259).

A square is to be used as a list symbol for the second level of an unnumbered list (cf. line 271)

[142]     .area
[143]     {
[144]       background-color: #CCCCCC;
[145]       border-style: solid;
[146]       border-width: thin;
[147]       border-color: black;
[148]       margin-bottom: 10pt;
[149]       margin-top: 10pt;
[150]       padding: 3px;
[151]     }

Each section of the document is to appear in a separate framed area. HTML element div is used for this and has a class attribute with the value area (cf. line 163, for example).

The area is given a grey background colour and a thin continuous border in black. In addition, a top and bottom margin of 10 points is defined for above and below the area. Finally, the area is also given a padding of 3 pixels.

[152]     .blockheading
[153]     {
[154]       color: #990000;
[155]     }

The headings within a long quote (blockquote element) are to appear in red (cf. line 186).

[156]     .highlight
[157]     {
[158]       background-color: yellow;
[159]     }

A separate class is defined for highlighted text (yellow background). Line 174 contains an example using the span element.

[163]     <div class="area">
[164] 	    <h1>Überschriften</h1>
[165] 	    <h2>Überschrift Ebene 2</h2>
[166] 	    <h3>Überschrift Ebene 3</h3>
[167] 	    <h4>Überschrift Ebene 4</h4>
[168] 	    <h5>Überschrift Ebene 5</h5>
[169] 	    <h6>Überschrift Ebene 6</h6>
[170]     </div>

This section and those that follow demonstrate the HTML elements available within an SLXHTML document. You can see the 6 heading levels here.

[171]     <div class="area">
[172]       <h1>Absätze, Inline-Formate</h1>    
[173]       <p>Ich bin ein Absatz. Leider ist mir nicht viel Text eingefallen.</p>
[174]       <p>Ich bin auch ein Absatz.<br/>Mein <span class="highlight">zweiter Satz</span>
[175]         steht in einer eigenen Zeile.</p>
[176]       <p>Ich enthalte folgendes Zitat aus <cite>unbekannter Quelle</cite>: 
[177]         <em>Schön war's.</em></p>
[178]       <p>Und ich enthalte Code: <code>int test = 4;</code></p>
[179]       <p>Ich möchte <em>betonen</em>, dass das nicht so gemeint war.</p>
[180]       <p>Ich enthalte als <strong>strong</strong> ausgezeichneten Text.</p>
[181]       <pre>I c h  bin  vorformatierter  Text.</pre>
[182]     </div>

Subsequently, the use of the generic inline element span, the inline elements cite, em, code and strong, the generic block-level element div, and block-level elements p and pre is illustrated.

[183]     <div class="area">
[184]       <h1>Blockweises Zitieren</h1>
[185]       <blockquote>
[186]         <h3 class="blockheading">Überschrift Ebene 3 innerhalb von 
[187]         <code>blockquote</code></h3>
[188]         <p>Absatz innerhalb von <code>blockquote</code></p>
[189]       </blockquote>
[190]     </div>

The blockquote block-level element is used for long quotes.

[191]     <div class="area">
[192]       <h1>Einfache Tabelle</h1>
[193]       <table class="simple">
[194]         <caption class="simple">Einfache Tabelle</caption>
[195]         <tr>
[196]           <th>Vorname</th>
[197]           <th>Nachname</th>
[198]           <th>Geburtsdatum</th>
[199]         </tr>
[200]         <tr>
[201]           <td>Homer</td>
[202]           <td>Simpson</td>
[203]           <td>05 .10. 1955</td>
[204]         </tr>
[205]         <tr>
[206]           <td>Bart</td>
[207]           <td>Simpson</td>
[208]           <td id="missing1">01 .04.</td>
[209]         </tr>
[210]       </table>
[211]     </div>

Above you can see a table in simple table format (without the elements thead, tbody and tfoot).

[212]     <div class="area">
[213]       <h1>Erweiterte Tabelle</h1>
[214]       <table class="extended">
[215]         <caption>Erweiterte Tabelle</caption>
[216]         <thead>
[217]         <tr>
[218]           <th colspan="2">Namen</th>
[219]           <th>Sonstiges</th>
[220]         </tr>
[220]         <tr>
[222]           <th>Vorname</th>
[223]           <th>Nachname</th>
[224]           <th>Geburtsdatum</th>
[225]         </tr>
[226]         </thead>
[227]         <tfoot>
[228]           <tr>
[229]             <th>Vorname</th>
[230]             <th>Nachname</th>
[231]             <th>Geburtsdatum</th>
[232]           </tr>
[233]         </tfoot>
[234]         <tbody>
[235]           <tr>
[236]             <td>Homer</td>
[237]             <td>Simpson</td>
[238]             <td>05 .10. 1955</td>
[239]           </tr>
[240]           <tr>
[241]             <td>Bart</td>
[242]             <td>Simpson</td>
[243]             <td id="missing2">01 .04.</td>
[244]           </tr>
[245]         </tbody>
[246]       </table>
[247]     </div>

Here you can see a table in extended table format. To begin with, the table is divided into thead, tfoot and tbody; the table rows (tr) with the table cells (th or td) occur within those.

[248]     <div class="area">
[249]       <h1>Bilder</h1>    
[250]       <p class="img">
[251]         <img alt="Logo A-Sit" src="LogoAsit.gif"></img>
[252]       </p>
[253]     </div>

An image is integrated in the area above. The alt attribute must always be specified with an alternative text for the img element.

[254]     <div class="area">
[255]   	  <h1>Numerierte Liste</h1>    
[256]         <ol>
[257]           <li>Erster Eintrag</li>
[258]         <li>Zweiter Eintrag
[259]           <ol class="level2">
[260]             <li>Erster Subeintrag</li>
[261]             <li>Zweiter Subeintrag</li>
[262]           </ol>
[263]         </li>
[264]       </ol>  
[265]     </div>

An example of a numbered list follows.

[266]     <div class="area">
[267]       <h1>Nicht numerierte Liste</h1>
[268]       <ul>
[269]         <li>Erster Eintrag</li>
[270]         <li>Zweiter Eintrag
[271]           <ul class="level2">
[272]             <li>Erster Subeintrag</li>
[273]             <li>Zweiter Subeintrag</li>
[274]           </ul>
[275]         </li>
[276]       </ul>  
[277]     </div>
[278]   </body>
[279] </html>

Finally, you will see an example of an unnumbered list.

Downloads for this example
Further information

4.3 Signing SLXHTML documents with images

Documents in the standardised viewer format SLXHTML that reference images (img element) can be signed by the Citizen Card Environment, but only if an XML signature is created; this option is not available for CMS signatures.

If the Citizen Card Environment can resolve a referenced image, it must show the image in the viewer component as part of the SLXHTML document and, when calculating the signature for the image, create a separate dsig:Reference element with a specially selected dsig:Reference/@Type attribute and a dsig:Reference/@URI attribute whose value corresponds to the img/@src attribute of the image reference.

If, on the other hand, the Citizen Card Environment cannot resolve a referenced image, instead of the image it must display the alternative text for the image (img/@alt) in the viewer component as part of the SLXHTML document and must not create a separate dsig:Reference element during calculation.

If the img/src attribute of an image reference contains a URL that cannot be resolved by the Citizen Card Environment, the application can add the image data in sl:CreateXMLSignatureRequest either directly (as sl:BinaryContent) or indirectly (as sl:LocRefContent) as a supplementary object (sl:Supplement) for the data to be signed (cf. example 2.1.2.5).

A Citizen Card Environment will certainly support images in gif and jpeg format, although several boundary conditions must be met.

4.3.1 Initial example

In the following example, an XML signature is to be created for an SLXHTML document containing an image reference that can be resolved by the Citizen Card Environment.

Request

Please note that for better readability, the example has been shortened and line breaks have been added (indicated by the \ character at the end of a line).

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:CreateXMLSignatureRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:KeyboxIdentifier>SecureSignatureKeypair</sl:KeyboxIdentifier>
[05]   <sl:DataObjectInfo Structure="enveloping">
[06]     <sl:DataObject>
[07]       <sl:XMLContent><html xmlns="http://www.w3.org/1999/xhtml">
[08]   <head>
[09]     <title>Ein einfaches SLXHTML-Dokument mit enthaltenem Bild</title>
[10]     <style type="text/css"/>
[11]   </head>
[12]   <body>
[13]     <p>Das nachfolgende Bild gibt einen Überblick zum Modell Bürgerkarte.</p>
[14]     <p>
[15]       <img src="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/\
[16] 20040514/tutorial/examples/viewerformat/ModellBuergerkarte.gif" 
[17]         alt="Modell Bürgerkarte"/>
[18]     </p>
[19]   </body>
[20] </html>
[21] </sl:XMLContent>
[22]     </sl:DataObject>
[23]     <sl:TransformsInfo>
[24]       <sl:FinalDataMetaInfo>
[25]         <sl:MimeType>application/xhtml+xml</sl:MimeType>
[26]       </sl:FinalDataMetaInfo>
[27]     </sl:TransformsInfo>
[28]   </sl:DataObjectInfo>
[29] </sl:CreateXMLSignatureRequest>

The SLXHTML document to be signed is specified in lines 7 to 21. Lines 15 to 17 contain the image reference with an http-URL that can be resolved by the Citizen Card Environment.

Response

The corresponding response from the Citizen Card Environment should look something like this. Please note that for better readability, the example has been formatted and shortened and line breaks have been added, although this naturally breaks the electronic signature.

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl11:CreateXMLSignatureResponse 
[03]   xmlns:sl11="http://www.buergerkarte.at/namespaces/securitylayer/20020831#">
[04]   <dsig:Signature Id="signature-02012005143921145" 
[05]     xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[06]     <dsig:SignedInfo>
[07]       ...
[08]       <dsig:Reference Id="reference-0-02012005143921145" URI="#signed-data-0-02012005143921145">
[09]         <dsig:Transforms>
[10]           <dsig:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
[11]             <xpf:XPath Filter="intersect" xmlns:xpf="http://www.w3.org/2002/06/xmldsig-filter2">\
[12] //*[@Id='signed-data-0-02012005143921145']/node()</xpf:XPath>
[13]           </dsig:Transform>
[14]         </dsig:Transforms>
[15]         <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[16]         <dsig:DigestValue>1f3BLWEdDbsRxP3MgQuJtARuVAM=</dsig:DigestValue>
[17]       </dsig:Reference>
[18]       ...
[19]       <dsig:Reference Id="reference-02012005143921145-addref-0" 
[20]         Type="http://www.buergerkarte.at/specifications/Security-Layer/20031031?\
[21] name=SignedImage&InstanceDocRef=0" 
[22]         URI="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/\
[23] tutorial/examples/viewerformat/ModellBuergerkarte.gif">
[24]         <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[25]         <dsig:DigestValue>BgP4msC8vf30udU9BmuNW+IqdEI=</dsig:DigestValue>
[26]       </dsig:Reference>
[27]     </dsig:SignedInfo>
[28]     ...
[29]     <dsig:Object Id="signed-data-0-02012005143921145">
[30]       <html version="-//www.buergerkarte.at//DOCUMENT SLXHTML 1.2//DE" 
[31]         xmlns="http://www.w3.org/1999/xhtml">
[32]         <head>
[33]           <title>Ein einfaches SLXHTML-Dokument mit enthaltenem Bild</title>
[34]           <style media="screen" type="text/css"/>
[35]         </head>
[36]         <body>
[37]           <p>Das nachfolgende Bild gibt einen Überblick zum Modell Bürgerkarte.</p>
[38]           <p>
[39]             <img alt="Modell Bürgerkarte" 
[40]               src="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/\
[41] 20040514/tutorial/examples/viewerformat/ModellBuergerkarte.gif"/>
[42]           </p>
[43]         </body>
[44]       </html>
[45]     </dsig:Object>
[46]   </dsig:Signature>
[47] </sl11:CreateXMLSignatureResponse>

Lines 8 to 17 contain the dsig:Reference to the signed SLXHTML document. The document itself is in the dsig:Object in lines 29 to 45.

Lines 19 to 26 contain the dsig:Reference created by the Citizen Card Environment for the image referenced from the SLXHTML document. The value of the Type attribute in lines 20 and 21 is http://www.buergerkarte.at/.../20031031?name=SignedImage&InstanceDocRef=0; the first part never changes, only the value of the URL parameter InstanceDocRef varies. This specifies an integer as the number of the dsig:Reference in dsig:SignedInfo of the XML signature referring to the SLXHTML document from which the image was referenced (counting starts at 0). The URI attribute (lines 22 and 23) contains precisely the same value as the img/@src attribute of the corresponding image (cf. lines 40 and 41).

Downloads for this example
Further information

4.3.2 Image data as supplementary object

The following example is a variation on the last one: The same SLXHTML document is to be signed, however the image reference is a local reference and thus cannot be resolved by the Citizen Card Environment. In the request, the application must therefore specify a supplementary object for the image data.

Request

Please note that for better readability, the example has been formatted and line breaks have been added (indicated by the \ character at the end of a line).

[01] <?xml version="1.0" encoding="UTF-8"?>
[02] <sl:CreateXMLSignatureRequest 
[03]   xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#">
[04]   <sl:KeyboxIdentifier>SecureSignatureKeypair</sl:KeyboxIdentifier>
[05]   <sl:DataObjectInfo Structure="enveloping">
[06]     <sl:DataObject>
[07]       <sl:XMLContent><html xmlns="http://www.w3.org/1999/xhtml">
[08]   <head>
[09]     <title>Ein einfaches SLXHTML-Dokument mit enthaltenem Bild</title>
[10]     <style type="text/css"/>
[11]   </head>
[12]   <body>
[13]     <p>Das nachfolgende Bild gibt einen Überblick zum Modell Bürgerkarte.</p>
[14]     <p>
[15]       <img src="ModellBuergerkarte.gif" alt="Modell Bürgerkarte"/>
[16]     </p>
[17]   </body>
[18] </html>
[19] </sl:XMLContent>
[20]     </sl:DataObject>
[21]     <sl:TransformsInfo>
[22]       <sl:FinalDataMetaInfo>
[23]         <sl:MimeType>application/xhtml+xml</sl:MimeType>
[24]       </sl:FinalDataMetaInfo>
[25]     </sl:TransformsInfo>
[26]     <sl:Supplement>
[27]       <sl:Content Reference="ModellBuergerkarte.gif">
[28]         <sl:Base64Content>...</sl:Base64Content>
[29]       </sl:Content>
[30]     </sl:Supplement>
[31]   </sl:DataObjectInfo>
[32] </sl:CreateXMLSignatureRequest>

It is apparent in line 15 that img/@src this time contains a relative image reference that cannot be resolved by the Citizen Card Environment.

For this reason, a supplementary object (cf. example 2.1.2.5) for the data to be signed is specified in line 26. The value of the sl:Content/@Reference attribute in line 27 matches exactly that of the img/@src value in line 15.

Response

The response from the Citizen Card Environment returns the same XML signature as the previous example and is therefore not explained further here.

Downloads for this example
Further information