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.4
Date 14-01-2014
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. Frequently used Interface commands
    1. Creating a signature in XMLDSIG format
    2. Creating a signature in CMS format
    3. Reading an info box
    4. Null operation
  3. Frequently used applications
    1. Result to the application server
    2. Transmitting identity link and sign document (Sign On)
  4. Specified but not frequently used commands
    1. Verify signatures
    2. Encrypt data
    3. Decrypt data
    4. Calculate hash value
    5. Verify hash value
    6. Reading out available info boxes
    7. Requesting properties
    8. Error handling
  5. Further applications
    1. Result to browser
    2. Signing files
  6. Default viewer format SLXHTML
    1. A first example
    2. A comprehensive example
    3. Signing SLXHTML document including pictures
  7. Overview citizen card environment support

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.

Section 5 shows samples for the use of the Citizen Card Environment.

Section 6 deals with the default viewer format of the Citizen Card. The basic structure of an appropriate XHTML document including a complex example, that shows the possibilities for structuring and formating the document, are demonstrated. The last part focuses on signing documents containing pictures.

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 Frequently used Interface commands

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

2.1. Creating a signature in XMLDSIG format

2.1.1. Initial example

2.1.1.1. Request

In this example the simple text Ich bin ein einfacher Text should be signed with the key that generates a secure signature. 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).

2.1.1.2. 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.

2.1.1.3. Downloads for this example
Further information

Tabelle 1. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
OK OK OK OK OK OK

2.1.2 Creating a signature in XMLDSIG with XHTML format

2.1.2.1. Request

This example is going to sign an XHTML document according to the default viewer format of the citizen card. 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>
[08] <html xmlns="http://www.w3.org/1999/xhtml">
[09] <head>
[10] <title>Ein einfaches SLXHTML-Dokument</title>
[11] <style type="text/css">p { color: red; }</style>
[12] </head>
[13] <body>
[14] <p>Ich bin ein einfacher Text in rot.</p>
[15] </body>
[16] </html>
[17] </sl:XMLContent>
[18] </sl:DataObject>
[19] <sl:TransformsInfo>
[20] <sl:FinalDataMetaInfo>
[21] <sl:MimeType>application/xhtml+xml</sl:MimeType>
[22] </sl:FinalDataMetaInfo>
[23] </sl:TransformsInfo>
[24] </sl:DataObjectInfo>
[25] </sl:CreateXMLSignatureRequest>
2.1.2.2. 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] xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[05] <dsig:Signature
[06] Id="Signature-bcb1202b-1"
[07] xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[08] <dsig:SignedInfo Id="SignedInfo-bcb1202b-1">
[09] <dsig:CanonicalizationMethod
[10] Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
[11] <dsig:SignatureMethod
[12] Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1"/>
[13] <dsig:Reference
[14] Id="Reference-bcb1202b-1" URI="#Object-bcb1202b-1">
[15] <dsig:Transforms>
[16] <dsig:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
[17] <XPath xmlns="http://www.w3.org/2002/06/xmldsig-filter2"
[18] Filter="intersect">id("Object-bcb1202b-1")/node()
[19] </XPath>
[20] </dsig:Transform>
[21] <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
[22] </dsig:Transforms>
[23] <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[24] <dsig:DigestValue>S0F8rHlmDPVVMO7TCjVJnp8bHaY=</dsig:DigestValue>
[25] </dsig:Reference>
[26] <dsig:Reference Id="Reference-bcb1202b-2"
[27] Type="http://uri.etsi.org/01903/v1.1.1#SignedProperties"
[28] URI="<!--...-->">
[29] <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[30] <dsig:DigestValue>WEbi/U1VfP2wJoSz9/tN5VKhBJc=</dsig:DigestValue>
[31] </dsig:Reference>
[32] </dsig:SignedInfo>
[33] <dsig:SignatureValue Id="SignatureValue-bcb1202b-1">
[34] 7cbwPE/a2yEHwW1OctKV9GdPwkXyfmQmlcklzP47H3ABm602kpb87c4u4ze7YkUQ
[35] fUO7HH3JGc1skXFJYchykA==
[36] </dsig:SignatureValue>
[37] <dsig:KeyInfo><!-- ... --></dsig:KeyInfo>
[38] <dsig:Object Id="Object-bcb1202b-1">
[39] <html xmlns="http://www.w3.org/1999/xhtml">
[40] <head>
[41] <title>Ein einfaches SLXHTML-Dokument</title>
[42] <style type="text/css">p { color: red; }</style>
[43] </head>
[44] <body>
[45] <p>Ich bin ein einfacher Text in rot.</p>
[46] </body>
[47] </html>
[48] </dsig:Object>
[49] <dsig:Object Id="Object-bcb1202b-2"><!-- ... --></dsig:Object>
[50] </dsig:Signature>
[51] </sl:CreateXMLSignatureResponse>
Downloads for this example
Further information

Tabelle 2. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
OK OK OK OK OK OK

2.1.3 MOA-ID Request

This example is the signature request from a MOA-ID instance. The SAML assertion that contains the data to be signed gets transformated with XLST to be better readable for the citizen.

2.1.3.1. Request
[001] <?xml version="1.0" encoding="utf-8"?>
[002] <sl:CreateXMLSignatureRequest xmlns:dsig='http://www.w3.org/2000/09/xmldsig#'
[003] xmlns:sl='http://www.buergerkarte.at/namespaces/securitylayer/1.2#'>
[004] <sl:KeyboxIdentifier>SecureSignatureKeypair</sl:KeyboxIdentifier>
[005] <sl:DataObjectInfo Structure='detached'>
[006] <sl:DataObject Reference='' />
[007] <sl:TransformsInfo>
[008] <dsig:Transforms xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[009] <dsig:Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">
[010] <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
[011] xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
[012] xmlns:pr="http://reference.e-government.gv.at/namespace/persondata/20020228#"
[013] exclude-result-prefixes="pr saml">
[014] <xsl:output method="xml" xml:space="default" />
[015] <xsl:template match="/" xmlns="http://www.w3.org/1999/xhtml">
[016] <html>
[017] <head>
[018] <title>Signatur der Anmeldedaten</title>
[019] <style type="text/css" media="screen">.normalstyle { font-size: medium; }
[020] .italicstyle { font-size: medium; font-style: italic; } .titlestyle{
[021] text-decoration:underline; font-weight:bold; font-size: medium; } .h4style{
[022] font-size: large; }</style>
[023] </head>
[024] <body>
[025] <h4 class="h4style">Anmeldedaten:</h4>
[026] <p class="titlestyle">Daten zur Person</p>
[027] <table class="parameters">
[028] <xsl:if test="normalize-space(//@Issuer)">
[029] <tr>
[030] <td class="italicstyle">Name:</td>
[031] <td class="normalstyle">
[032] <xsl:value-of select="//@Issuer" />
[033] </td>
[034] </tr>
[035] </xsl:if>
[036] <xsl:if test="string(//saml:Attribute[@AttributeName='Geburtsdatum']/saml:AttributeValue)">
[037] <tr>
[038] <td class="italicstyle">Geburtsdatum:</td>
[039] <td class="normalstyle">
[040] <xsl:value-of select="substring(//saml:Attribute[@AttributeName='Geburtsdatum']/saml:AttributeValue,9,2)" />
[041] <xsl:text>.</xsl:text>
[042] <xsl:value-of select="substring(//saml:Attribute[@AttributeName='Geburtsdatum']/saml:AttributeValue,6,2)" />
[043] <xsl:text>.</xsl:text>
[044] <xsl:value-of select="substring(//saml:Attribute[@AttributeName='Geburtsdatum']/saml:AttributeValue,1,4)" />
[045] </td>
[046] </tr>
[047] </xsl:if>
[048] <xsl:if test="//saml:Attribute[@AttributeName='OIDTextualDescription']">
[049] <tr>
[050] <td class="italicstyle">Rolle:</td>
[051] <td class="normalstyle">
[052] <xsl:value-of select="//saml:Attribute[@AttributeName='OIDTextualDescription']/saml:AttributeValue" />
[053] </td>
[054] </tr>
[055] </xsl:if>
[056] <xsl:if test="//saml:Attribute[@AttributeName='mandateReferenceValue']">
[057] <tr>
[058] <td class="italicstyle">Vollmacht:</td>
[059] <td class="normalstyle">
[060] <xsl:text>Ich melde mich in Vertretung an. Im nächsten Schritt wird mir eine Liste der für mich
[061] verfügbaren Vertretungsverhältnisse angezeigt, aus denen ich eines auswählen werde.</xsl:text>
[062] </td>
[063] </tr>
[064] </xsl:if>
[065] </table>
[066] <p class="titlestyle">Daten zur Anwendung</p>
[067] <table class="parameters">
[068] <tr>
[069] <td class="italicstyle">Name:</td>
[070] <td class="normalstyle">
[071] <xsl:value-of select="//saml:Attribute[@AttributeName='oaFriendlyName']/saml:AttributeValue" />
[072] </td>
[073] </tr>
[074] <tr>
[075] <td class="italicstyle">Staat:</td>
[076] <td class="normalstyle">Österreich</td>
[077] </tr>
[078] </table>
[079] <p class="titlestyle">Technische Parameter</p>
[080] <table class="parameters">
[081] <tr>
[082] <td class="italicstyle">URL:</td>
[083] <td class="normalstyle">
[084] <xsl:value-of select="//saml:Attribute[@AttributeName='OA']/saml:AttributeValue" />
[085] </td>
[086] </tr>
[087] <xsl:if test="//saml:Attribute[@AttributeName='Geschaeftsbereich']">
[088] <tr>
[089] <td class="italicstyle">Bereich:</td>
[090] <td class="normalstyle">
[091] <xsl:value-of select="//saml:Attribute[@AttributeName='Geschaeftsbereich']/saml:AttributeValue" />
[092] </td>
[093] </tr>
[094] </xsl:if>
[095] <xsl:if test="//saml:Attribute[@AttributeName='mandateReferenceValue']">
[096] <tr>
[097] <td class="italicstyle">Vollmachten-Referenz:</td>
[098] <td class="normalstyle">
[099] <xsl:value-of select="//saml:Attribute[@AttributeName='mandateReferenceValue']" />
[100] </td>
[101] </tr>
[102] </xsl:if>
[103] <xsl:if test="//saml:Attribute[@AttributeName='IdentityLinkDomainIdentifierType']">
[104]
[105] <tr>
[106] <td class="italicstyle">
[107] <xsl:value-of select="//saml:Attribute[@AttributeName='IdentityLinkDomainIdentifierType']" />:</td>
[108] <td class="normalstyle">
[109] <xsl:value-of select="//saml:Attribute[@AttributeName='wbPK']/saml:AttributeValue/pr:Identification/pr:Type" />
[110] </td>
[111] </tr>
[112] </xsl:if>
[113] <xsl:if test="//saml:Attribute[@AttributeName='bPK'] or //saml:Attribute[@AttributeName='wbPK']">
[114]
[115] <tr>
[116] <td class="italicstyle">Identifikator:</td>
[117] <td class="normalstyle">
[118] <xsl:value-of select="//saml:Attribute[@AttributeName='bPK']/saml:AttributeValue/pr:Identification/pr:Value"/>
[119] <xsl:value-of select="//saml:Attribute[@AttributeName='wbPK']/saml:AttributeValue/pr:Identification/pr:Value"/>
[120] </td>
[121] </tr>
[122] </xsl:if>
[123] <xsl:if test="//saml:Attribute[@AttributeName='OIDTextualDescription']">
[124] <tr>
[125] <td class="italicstyle">OID:</td>
[126] <td class="normalstyle">
[127] <xsl:value-of select="//saml:Attribute[@AttributeName='OID']/saml:AttributeValue" />
[128] </td>
[129] </tr>
[130] </xsl:if>
[131] <xsl:if test="//saml:Attribute[@AttributeName='HPI']">
[132] <tr>
[133] <td class="italicstyle">HPI:</td>
[134] <td class="normalstyle">
[135] <xsl:value-of select="//saml:Attribute[@AttributeName='HPI']/saml:AttributeValue" />
[136] </td>
[137] </tr>
[138] </xsl:if>
[139] <tr>
[140] <td class="italicstyle">Datum:</td>
[141] <td class="normalstyle">
[142] <xsl:value-of select="substring(//@IssueInstant,9,2)" />
[143] <xsl:text>.</xsl:text>
[144] <xsl:value-of select="substring(//@IssueInstant,6,2)" />
[145] <xsl:text>.</xsl:text>
[146] <xsl:value-of select="substring(//@IssueInstant,1,4)" />
[147] </td>
[148] </tr>
[149] <tr>
[150] <td class="italicstyle">Uhrzeit:</td>
[151] <td class="normalstyle">
[152] <xsl:value-of select="substring(//@IssueInstant,12,2)" />
[153] <xsl:text>:</xsl:text>
[154] <xsl:value-of select="substring(//@IssueInstant,15,2)" />
[155] <xsl:text>:</xsl:text>
[156] <xsl:value-of select="substring(//@IssueInstant,18,2)" />
[157] </td>
[158] </tr>
[159] </table>
[160] </body>
[161] </html>
[162] </xsl:template>
[163] </xsl:stylesheet>
[164] </dsig:Transform>
[165] <dsig:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments" />
[166] </dsig:Transforms>
[167] <sl:FinalDataMetaInfo>
[168] <sl:MimeType>application/xhtml+xml</sl:MimeType>
[169] </sl:FinalDataMetaInfo>
[170] </sl:TransformsInfo>
[171] </sl:DataObjectInfo>
[172] <sl:SignatureInfo>
[173] <sl:SignatureEnvironment>
[174] <sl:XMLContent>
[175] <saml:Assertion xmlns:saml='urn:oasis:names:tc:SAML:1.0:assertion'
[176] xmlns:pr="http://reference.e-government.gv.at/namespace/persondata/20020228#"
[177] MajorVersion='1' MinorVersion='0' AssertionID='any'
[178] Issuer='XXXMaria-Theresia Kunigunda XXXHabsburg-Lothringen'
[179] IssueInstant='2012-02-15T12:06:14+01:00'>
[180] <saml:AttributeStatement>
[181] <saml:Subject>
[182] <saml:NameIdentifier>https://localhost:8443/moa-id-auth/</saml:NameIdentifier>
[183] </saml:Subject>
[184] <saml:Attribute AttributeName='Geschaeftsbereich'
[185] AttributeNamespace='http://reference.e-government.gv.at/namespace/moa/20020822#'>
[186] <saml:AttributeValue>ZU (Zustellungen)</saml:AttributeValue>
[187] </saml:Attribute>
[188] <saml:Attribute AttributeName='OA'
[189] AttributeNamespace='http://reference.e-government.gv.at/namespace/moa/20020822#'>
[190] <saml:AttributeValue>
[191] https://localhost:8443/TestMOAID_OA/LoginServletExample</saml:AttributeValue>
[192] </saml:Attribute>
[193] <saml:Attribute AttributeName='Geburtsdatum'
[194] AttributeNamespace='http://reference.e-government.gv.at/namespace/moa/20020822#'>
[195] <saml:AttributeValue>1980-02-29</saml:AttributeValue>
[196] </saml:Attribute>
[197] <saml:Attribute AttributeName='bPK'
[198] AttributeNamespace='http://reference.e-government.gv.at/namespace/moa/20020822#'>
[199] <saml:AttributeValue>
[200] <pr:Identification xmlns:pr="http://reference.e-government.gv.at/namespace/persondata/20020228#">
[201] <pr:Value>XFPZNvBVBphHPVfqntB7k9QEZCQ=</pr:Value>
[202] <pr:Type>urn:publicid:gv.at:cdid+bpk</pr:Type>
[203] </pr:Identification>
[204] </saml:AttributeValue>
[205] </saml:Attribute>
[206] <saml:Attribute AttributeName='oaFriendlyName'
[207] AttributeNamespace='http://reference.e-government.gv.at/namespace/moa/20020822#'>
[208] <saml:AttributeValue>LoginServlet</saml:AttributeValue>
[209] </saml:Attribute>
[210] </saml:AttributeStatement>
[211] </saml:Assertion>
[212] </sl:XMLContent>
[213] </sl:SignatureEnvironment>
[214] <sl:SignatureLocation xmlns:saml='urn:oasis:names:tc:SAML:1.0:assertion' Index='2'>
[215] /saml:Assertion</sl:SignatureLocation>
[216] </sl:SignatureInfo>
[217] </sl:CreateXMLSignatureRequest>

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

Lines 7 to 169 contain the XSLT transformation. An XHTML site containing the information from the SAML assertion is generated.

Lines 172 to 212 contain the SAML assertion, that delivers the person's data that wants to sign in to the web application.

Lines 213 to 214 defines the signature location for the security layer request. It points to the SAML assertion in line 174 within the signature environment, so the CCE knows which SAML assertion to use.

2.1.3.2. 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] xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[05] <saml:Assertion
[06] xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
[07] xmlns:pr="http://reference.e-government.gv.at/namespace/persondata/20020228#"
[08] AssertionID="any" IssueInstant="2012-02-15T12:06:14+01:00"
[09] Issuer="XXXMaria-Theresia Kunigunda XXXHabsburg-Lothringen" MajorVersion="1" MinorVersion="0">
[10] <saml:AttributeStatement>
[11] <saml:Subject>
[12] <saml:NameIdentifier>https://localhost:8443/moa-id-auth/</saml:NameIdentifier>
[13] </saml:Subject>
[14] <saml:Attribute AttributeName="Geschaeftsbereich" AttributeNamespace="http://reference.e-government.gv.at/namespace/moa/20020822#">
[15] <saml:AttributeValue>ZU (Zustellungen)</saml:AttributeValue>
[16] </saml:Attribute>
[17] <saml:Attribute AttributeName="OA" AttributeNamespace="http://reference.e-government.gv.at/namespace/moa/20020822#">
[18] <saml:AttributeValue>https://localhost:8443/TestMOAID_OA/LoginServletExample</saml:AttributeValue>
[19] </saml:Attribute>
[20] <saml:Attribute AttributeName="Geburtsdatum" AttributeNamespace="http://reference.e-government.gv.at/namespace/moa/20020822#">
[21] <saml:AttributeValue>1980-02-29</saml:AttributeValue>
[22] </saml:Attribute>
[23] <saml:Attribute AttributeName="bPK" AttributeNamespace="http://reference.e-government.gv.at/namespace/moa/20020822#">
[24] <saml:AttributeValue>
[25] <pr:Identification xmlns:pr="http://reference.e-government.gv.at/namespace/persondata/20020228#">
[26] <pr:Value>XFPZNvBVBphHPVfqntB7k9QEZCQ=</pr:Value>
[27] <pr:Type>urn:publicid:gv.at:cdid+bpk</pr:Type>
[28] </pr:Identification>
[29] </saml:AttributeValue>
[30] </saml:Attribute>
[31] <saml:Attribute AttributeName="oaFriendlyName" AttributeNamespace="http://reference.e-government.gv.at/namespace/moa/20020822#">
[32] <saml:AttributeValue>LoginServlet</saml:AttributeValue>
[33] </saml:Attribute>
[34] </saml:AttributeStatement>
[35] <dsig:Signature Id="Signature-f44222c6-1" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[36] <dsig:SignedInfo Id="SignedInfo-f44222c6-1">
[37] <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
[38] <dsig:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1"/>
[39] <dsig:Reference Id="Reference-f44222c6-1" URI="">
[40] <dsig:Transforms xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[41] <dsig:Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">...</dsig:Transform>
[42] <dsig:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/>
[43] </dsig:Transforms>
[44] <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[45] <dsig:DigestValue>6dgHwwyn7GRWWwOTjjrrnqqckYM=</dsig:DigestValue>
[46] </dsig:Reference>
[47] <dsig:Reference Id="Reference-f44222c6-2" Type="http://uri.etsi.org/01903/v1.1.1#SignedProperties" URI="...">
[48] <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[49] <dsig:DigestValue>B1JYXQzg4uPHkA48ZKlJ8S8zZBQ=</dsig:DigestValue>
[50] </dsig:Reference>
[51] </dsig:SignedInfo>
[52] <dsig:SignatureValue Id="SignatureValue-f44222c6-1">...</dsig:SignatureValue>
[53] <dsig:KeyInfo>...</dsig:KeyInfo>
[54] <dsig:Object Id="Object-f44222c6-1">....</dsig:Object>
[55] </dsig:Signature>
[56] </saml:Assertion>
[57] </sl:CreateXMLSignatureResponse>
2.1.3.3. Downloads for this example
2.1.3.4. Further information

Tabelle 3. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
OK OK OK OK OK OK

2.1.4. Detached Signature of a PDF document

This example shows a detached XML signature of a PDF document. This request signs a PDF document and inserts the XML signature into an XML file.

2.1.4.1. Request
To increase readability the following example is formated in an appropriate way ('\' on Line endings!).
[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="file:sample.pdf">
[06] <sl:Base64Content>JVB...T0YK</sl:Base64Content>
[07] </sl:DataObject>
[08] <sl:TransformsInfo>
[09] <sl:FinalDataMetaInfo>
[10] <sl:MimeType>application/pdf</sl:MimeType>
[11] </sl:FinalDataMetaInfo>
[12] </sl:TransformsInfo>
[13] </sl:DataObjectInfo>
[14] <sl:SignatureInfo>
[15] <sl:SignatureEnvironment Reference="file:sample.xml">
[16] <sl:XMLContent>
[17] <arch:Dossier xmlns:arch="http://www.anwaltsarchiv.at/Archivium/1.0" \
[18] xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
[19] <arch:DossierProfile version="2.0">
[20] <arch:CreationDate>24.04.2012</arch:CreationDate>
[21] <arch:Subject>
[22] <arch:Name>Testdokument</arch:Name>
[23] <arch:DigestValue>DYivXbD4Z7xwYpBsH6jB1JvN0Pw=</arch:DigestValue>
[24] </arch:Subject>
[25] </arch:DossierProfile>
[26] <arch:Documents>
[27] <arch:Document>
[28] <arch:DocumentProfile>
[29] <arch:FileName>sample.xml</arch:FileName>
[30] <arch:SourceLocation>file:sample.pdf</arch:SourceLocation>
[31] <arch:MimeType>application/pdf</arch:MimeType>
[32] <arch:SourceSize>332129</arch:SourceSize>
[33] </arch:DocumentProfile>
[34] </arch:Document>
[35] </arch:Documents>
[36] </arch:Dossier>
[37] </sl:XMLContent>
[38] </sl:SignatureEnvironment>
[39] <sl:SignatureLocation xmlns:arch="http://www.anwaltsarchiv.at/Archivium/1.0" Index="2">/arch:Dossier</sl:SignatureLocation>
[40] </sl:SignatureInfo>
[41] </sl:CreateXMLSignatureRequest>
2.1.4.2. 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] <arch:Dossier xmlns:arch="http://www.anwaltsarchiv.at/Archivium/1.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
[04] <arch:DossierProfile version="2.0">
[05] <arch:CreationDate>24.04.2012</arch:CreationDate>
[06] <arch:Subject>
[07] <arch:Name>Testdokument</arch:Name>
[08] <arch:DigestValue>DYivXbD4Z7xwYpBsH6jB1JvN0Pw=</arch:DigestValue>
[09] </arch:Subject>
[10] </arch:DossierProfile>
[11] <dsig:Signature Id="signature-1335440286-522638192-931345" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[12] <dsig:SignedInfo>
[13] ...
[14] </dsig:SignedInfo>
[15] <dsig:SignatureValue>yxsAD20SIkGYlz16fZ/qbF3CSQ6Jx90Yb2pbiHkDPVl3q64y+syyFQEL1eRpWPfk</dsig:SignatureValue>
[16] <dsig:KeyInfo>
[17] ...
[18] </dsig:KeyInfo>
[19] <dsig:Object Id="etsi-data-object-0-1335440286-522638192-931345">
[20] </dsig:Object>
[21] </dsig:Signature>
[22] <arch:Documents>
[23] <arch:Document>
[24] <arch:DocumentProfile>
[25] <arch:FileName>sample.xml</arch:FileName>
[26] <arch:SourceLocation>file:sample.pdf</arch:SourceLocation>
[27] <arch:MimeType>application/pdf</arch:MimeType>
[28] <arch:SourceSize>332129</arch:SourceSize>
[29] </arch:DocumentProfile>
[30] </arch:Document>
[31] </arch:Documents>
[32] </arch:Dossier>
[33] </sl:CreateXMLSignatureResponse>
2.1.4.3. Downloads for this example
2.1.4.4. Further information

Tabelle 4. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
OK OK NOT IMPLEMENTED OK OK OK

2.2. Creating a signature in CMS format

2.2.1 Initial example

2.2.1.1. 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.

2.2.1.2. 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).

2.2.1.3. Downloads for this example
2.2.1.4. Further information

Tabelle 5. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED OK OK OK OK

2.2.2. Specifying data to be signed as a reference

2.2.2.1. 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>SecureSignatureKeypair</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] aktuell/tutorial/examples/viewerformat/Simple.xhtml"/>
[13] </sl:DataObject>
[14] </sl:CreateCMSSignatureRequest>

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.

2.2.2.2.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#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
[03] <sl:CMSSignature>MIIInQYJKoZIhvcNAQcCoIIIjjCCCIoCAQExDzANBglghkgBZQMEAgEFADCCATMGCSqGSIb3DQEH
[04] AaCCASQEggEgPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxodG1sIHht
[05] ...
[06] /O9kiGPcH9gCIQCPLfUv11nyXItN1wctAUuURpBj5dji8v4uUxFf4JXsHw==</sl:CMSSignature>
[07] </sl:CreateCMSSignatureResponse>

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

Lines 3 to 6 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).

2.2.2.3. Downloads for this example
2.2.2.4. Further information

Tabelle 6. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED OK OK OK OK

2.3. Reading an info box

2.3.1. 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.

2.3.1.1. 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>
Line 4 contains the identifier of the info box to read (TutorialBinary).
The next entry MUST contain the (empty) element sl:BinaryFileParameters (Line 5). The optional attribute ContentIsXMLEntity set to true in this example tells the Citizen Card Environment that the content of the info box represents an amount of XML nodes (may not be a complete XML document with one single root element). The Citizen Card Environment will consider this fact in the command request.
The element sl:BoxSpecificParameters in line 6 to 9 may contain info-box-specific parameters. For the IdentityLink info box the element may contain the sl:IdentityLinkDomainIdentifier.

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).

2.3.1.2.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: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>
The response contains one single child element sl:BinaryFileData (line 4 to 72). The CCE decides to encode the content of the info box either as XML structure (sl:XMLContent) or as base64-encoded binary value (sl:Base64Content). Because line5 explicitly states that the content of the infobox is XML based, the CCE will return the content as XML structure (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.

2.3.1.3. Downloads for this example
2.3.1.4. Further information

Tabelle 7. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
OK OK OK OK OK OK

2.3.2. Reading the SecureSignatureKeypair

This example shows how to read the certificate according to the SecureSignatureKeypair from the standardised Certificates info box.

2.3.2.1. 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.

2.3.2.2. 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.

2.3.2.3. Downloads for this example
2.3.2.4. Further information

Tabelle 8. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
OK OK OK OK OK OK

2.4. 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.

2.4.1. 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.

2.4.2. 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.

2.4.3. Downloads for this example

2.4.4. Further information

Tabelle 9. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
OK OK OK OK OK OK

3. Frequently used applications

3.1. Result to application server

By defining the form parameter DataUrl within the HTTP request the Citizen Card Environment is determined to send the XML response to the application server defined within DataUrl instead of sending it back to the browser.

The reaction of the application server and additional form parameters within the request define which data is sent from the CCE to the browser within the response.

The following examples will demonstrate some of the possible combinations.

Note: You may try the example by yourself . The J2EE web application can be found in the web archive. Deploy your application in such a way that the root context is available under http://localhost:8080/SL12Tutorial/ respective https://localhost:8443/SL12Tutorial/ . The web application is only a prototype and should NOT be used for productive use.

3.1.1. Asynchronous user guidance using RedirectURL and DataURL

Beneath the XML-command request the following example will contain two additional form parameters:

The following sequence will be realized by combining this two parameters:
  1.  The citizen sends an HTTP request with the XMLRequest (in this example a NullOperationRequest) and the two parameters DataURL and RedirectURL to the CCE.
  2. Die CCE answers the request with an HTTP Redirect (Code 302 or 303) to the location set by RedirectURL. This location is part of the application and acts as a holding stack, where the citizen has to wait until the answer from the CCE is received by the application (see step 3).
  3. The CCE processes the XML-command request and sends the XML-command response via an HTTP POST request to the location specified by DataURL, which is a part of the application.
  4. The application acknowledges the CCE in HTTP response the correct reception of the XML-command response.
  5. The application processes the XML-command response and answers the citizen instead of continuing with the holding site in the next step.

3.1.1.1. HTML-Formular

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'?><NullOperationRequest \
[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>
Line 10 to 12 represents the form parameter DataURL, line 13 to 15 represent the form parameter RedirectURL.
Both of the URLs contain the session ID which is used to connect the users browser in the holding stack to the XML-command response sent from the CCE to the application. The session ID has to be a part of the URLs; using cookies is not possible because the application has to deal with two different clients (users's browser and CCE).

3.1.1.2. HTTP Request from the browser to the CCE

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:3495
[03] User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
[04] Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
[05] Accept-Language: en-us,en;q=0.5
[06] Accept-Encoding: gzip, deflate
[07] Connection: keep-alive
[08] Referer: http://localhost:8080/SL12Tutorial/Redirect
[09] Content-Type: application/x-www-form-urlencoded
[10] Content-Length: 477
[11]
[12] XMLRequest=%3C%3Fxml+version%3D%271.0%27+encoding%3D%27UTF-8%27%3F%3E%3CNullOperationRequest\
[13] +xmlns%3D%27http%3A%2F%2Fwww.buergerkarte.at%2Fnamespaces%2Fsecuritylayer%2F1.2%23%27%2F%3E&DataURL\
[14] =http%3A%2F%2Flocalhost%3A8080%2FSL12Tutorial%2FRedirect%3Bjsessionid%3D0D7EC8ECBDB4875E3B6D758A5615F178\
[15] %3Fuse%3Ddataurl&RedirectURL=http%3A%2F%2Flocalhost%3A8080%2FSL12Tutorial%2FRedirect%3Bjsessionid%3D0D7EC8ECBDB\
[16] 4875E3B6D758A5615F178%3Fuse%3Dredirecturl&Request+absenden=Submit+Query

3.1.1.3. HTTP Response from the CCE to the browser

Here you can see the HTTP response from the CCE 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 Found
[02] Location: http://localhost:8080/SL12Tutorial/Redirect;jsessionid=\
[03] 0D7EC8ECBDB4875E3B6D758A5615F178?use=redirecturl
[04] Content-Length: 0
An HTTP Redirect (line 1 Code 302) was sent. The header Location contains the value from the form parameter RedirectURL.

3.1.1.4. HTTP Request/Response to/from RedirectURL

Here you can see the HTTP request from the browser to the RedirectURL as well as the HTTP response of the application behind it. Please note that line breaks have been added (indicated by the \ character at the end of a line) for better readability.
[01] GET /SL12Tutorial/Redirect;jsessionid=0D7EC8ECBDB4875E3B6D758A5615F178?use=redirecturl HTTP/1.1
[02] Host: localhost:8080
[03] User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
[04] Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
[05] Accept-Language: en-us,en;q=0.5
[06] Accept-Encoding: gzip, deflate
[07] Connection: keep-alive
[08] Referer: http://localhost:8080/SL12Tutorial/Redirect
[09] Cookie: JSESSIONID=0D7EC8ECBDB4875E3B6D758A5615F178; player-616e6479=2; player-null=2
[01] HTTP/1.1 200 OK
[02] Server: Apache-Coyote/1.1
[03] Content-Type: text/html
[04] Content-Length: 383
[05] Date: Thu, 29 Mar 2012 11:45:44 GMT
[06]
[07] <html>
[08] <head>
[09] <title>Redirect: Warteschleife</title>
[10] <meta http-equiv="refresh" content="10; URL=http://localhost:8080/SL12Tutorial/Redirect;\
[11] jsessionid=0D7EC8ECBDB4875E3B6D758A5615F178;jsessionid=0D7EC8ECBDB4875E3B6D758A5615F178?use=redirecturl"/>
[12] </head>
[13] <body>
[14] <p>Bitte warten. Sobald die Antwort von der BKU eingetroffen ist, wird sie hier angezeigt.</p>
[15] </body>
[16] </html>
The aplication's answer page represents a holding stack. Line 10 contains a meta tag that tells the browser to refresh the page every 10 seconds.

3.1.1.5. HTTP Request from the CCE to the DataURL

Here you can see the HTTP request from the CCE to the application behind the DataURL. Please note that line breaks have been added (indicated by the \ character at the end of a line) for better readability.
[01] POST /SL12Tutorial/Redirect;jsessionid=0D7EC8ECBDB4875E3B6D758A5615F178?use=dataurl HTTP/1.1
[02] User-Agent: citizen-card-environment/1.2 MOCCA/1.3.7-SNAPSHOT-rnull
[03] SignatureLayout: 1.0
[04] Content-Type: application/x-www-form-urlencoded
[05] Host: localhost:8080
[06] Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
[07] Connection: keep-alive
[08] Content-Length: 336
[09]
[10] ResponseType=HTTP-Security-Layer-RESPONSE&XMLResponse=%3C%3Fxml+version%3D%221.0%22+encoding%3D\
[11] %22UTF-8%22+standalone%3D%22yes%22%3F%3E%0A%3Csl%3ANullOperationResponse+xmlns%3Asl%3D%22http%3A\
[12] %2F%2Fwww.buergerkarte.at%2Fnamespaces%2Fsecuritylayer%2F1.2%23%22+xmlns%3Adsig%3D%22http%3A%2F\
[13] %2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23%22%2F%3E%0A
As seen in line 1 it is an HTTP POST request.
Line 2 contains the identifier of the CCE as User-Agent.
The payload consists of some form parameters that are encoded as either application/x-www-form-urlencoded or as mutipart/form-data. At least they MUST contain the parameter XMLResponse with the XML-command response as well as the parameter ResponseType with the fixed value HTTP-Security-Layer-RESPONSE.

3.1.1.6. HTTP Response from DataURL to the CCE

The following example represents the HTTP response from the application, represented by DataURL, to the CCE.
[01] HTTP/1.1 200 OK
[02] Server: Apache-Coyote/1.1
[03] Content-Type: text/plain
[04] Content-Length: 5
[05] Date: Thu, 29 Mar 2012 11:45:44 GMT
[06]
[07] <ok/>
This represents an acknowledgment, that the application correctly received the XML-command response. The payload MUST exactly look like <ok/>. The header Content-Type may contain the value text/xml or text/plain or text/html.

3.1.1.7. Final HTTP Response from RedirectURL

The following example represents the final response from the application behind RedirectURL to the citizen's browser. This response is sent immediately after the application has finished the evaluation of the XML-command response from the CCE. 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] Server: Apache-Coyote/1.1
[03] Content-Type: text/html
[04] Content-Length: 381
[05] Date: Thu, 29 Mar 2012 11:45:54 GMT
[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" standalone="yes"?>
[14] <sl:NullOperationResponse xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"/>
[15] </pre></p>
[16] </body>
[17] </html>
3.1.1.8. Downloads for this example
3.1.1.9. Further information

Tabelle 10. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
OK OK OK OK OK OK

3.1.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.1.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.
3.1.2.1. 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'?><NullOperationRequest \
[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.

3.1.2.2. 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:3495
[03] User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
[04] Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
[05] Accept-Language: en-us,en;q=0.5
[06] Accept-Encoding: gzip, deflate
[07] Connection: keep-alive
[08] Referer: http://localhost:8080/SL12Tutorial/DataURL
[09] Content-Type: application/x-www-form-urlencoded
[10] Content-Length: 292
[11]
[12] XMLRequest=%3C%3Fxml+version%3D%271.0%27+encoding%3D%27UTF-8%27%3F%3E%3CNullOperationRequest+xmlns\
[13] %3D%27http%3A%2F%2Fwww.buergerkarte.at%2Fnamespaces%2Fsecuritylayer%2F1.2%23%27%2F%3E&DataURL=http\
[14] %3A%2F%2Flocalhost%3A8080%2FSL12Tutorial%2FDataURL%3Fuse%3Ddataurl&Request+absenden=Submit+Query
3.1.2.3. 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] User-Agent: citizen-card-environment/1.2 MOCCA/1.3.7-SNAPSHOT-rnull
[03] SignatureLayout: 1.0
[04] Content-Type: application/x-www-form-urlencoded
[05] Host: localhost:8080
[06] Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
[07] Connection: keep-alive
[08] Content-Length: 336
[09]
[10] ResponseType=HTTP-Security-Layer-RESPONSE&XMLResponse=%3C%3Fxml+version%3D%221.0%22+encoding\
[11] %3D%22UTF-8%22+standalone%3D%22yes%22%3F%3E%0A%3Csl%3ANullOperationResponse+xmlns%3Asl%3D\
[12] %22http%3A%2F%2Fwww.buergerkarte.at%2Fnamespaces%2Fsecuritylayer%2F1.2%23%22+xmlns\
[13] %3Adsig%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23%22%2F%3E%0A

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

Line 2 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.

3.1.2.4. 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] Server: Apache-Coyote/1.1
[03] Content-Type: text/html
[04] Content-Length: 397
[05] Date: Thu, 29 Mar 2012 12:11:47 GMT
[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" standalone="yes"?>
[14] <sl:NullOperationResponse xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"/>
[15] </pre></p>
[16] </body>
[17] </html>

In contrast to example 3.1.1, the payload of the HTTP response does not consist of a simple <ok/> string, but of an HTML document (cf. lines 7 to 17). 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.

3.1.2.5. 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] Server: citizen-card-environment/1.2 MOCCA/1.3.7-SNAPSHOT-rnull
[03] SignatureLayout: 1.0
[04] Date: Thu, 29 Mar 2012 12:11:47 GMT
[05] Content-Length: 397
[06] Content-Type: text/html; charset=utf-8
[07]
[08] <html>
[09] <head>
[10] <title>DataURL: Auswertung</title>
[11] </head>
[12] <body>
[13] <p>Die Antwort von der BKU ist eingetroffen:</p>
[14] <p><pre style="background-color: silver;"><?xml version="1.0" encoding="UTF-8" standalone="yes"?>
[15] <sl:NullOperationResponse xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/1.2#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"/>
[16] </pre></p>
[17] </body>
[18] </html>

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

3.1.2.6. Downloads for this example
3.1.2.7. Further information

Tabelle 11. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
OK OK OK OK OK OK

3.1.3 Using forwarding parameters and forwarding headers

The procedure in the following example is basically the same as in example 3.1.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 5.2.1.

3.1.3.1. 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).

3.1.3.2. 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
3.1.3.3. 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.

3.1.3.4. 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.

3.1.3.5. 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>
3.1.3.6. Downloads for this example
3.1.3.7. Further information

Tabelle 12. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
OK OK OK OK OK OK

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

This example shows a variation of the basic procedure shown in section 3.1.2.

Until now two possible reactions from the application server behind DataURL according to the HTTP request had been demonstrated: On the one hand the simple acknowledgment to the reception of the XML-command request, on the other hand an HTML document that has to be forwarded from the CCE to the citizen's browser without modifications.

As a third variant the application server may send an XML command within the HTTP response to the CCE that has to process it. Three different approaches are possible:

  1. The application server only sends the new XML command. All the other form fields (form parameter, forwarding parameter, forwarding header and other form fields) stay unchanged from the last, by the CCE, executed command.
  2. The application server sends a new XML command as well as a new value for the form parameter DataURL. All the other form fields stay unchanged form the last, by the CCE, executed command.
  3. The application server sends a complete set of form fields (form parameter, forwarding parameter, forwarding header, other fields).
This example presents a solution for reading the info box IdentityLink followed by signing the document by the citizen.
  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.
3.2.1. 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.

3.2.2. 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
3.2.3. First HTTP request from the Citizen Card Environment to DataURL
Now you see the first HTTP request fromt the CCE to the application behind DataURL. It contains the XML-command response for InfoboxReadResponse. It contains the XML response to the InfoboxRead command with the read-out person identity link. 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] POST /SL12Tutorial/SignOn;jsessionid=E4C29CF18AA19126394243036318B88F?use=sign HTTP/1.1
[02] User-Agent: citizen-card-environment/1.2 MOCCA/1.3.6-SNAPSHOT-r985
[03] SignatureLayout: 1.0
[04] Content-Type: application/x-www-form-urlencoded
[05] Host: localhost:8080
[06] Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
[07] Connection: keep-alive
[08] Content-Length: 8758
[09]
[10] ResponseType=HTTP-Security-Layer-RESPONSE&XMLResponse=%3C%3Fxml+version%3D%221.0%22+encoding\
[11] %3D%22UTF-8%22%3F%3E%3Csl%3AInfoboxReadResponse+xmlns%3Asl%3D%22http%3A%2F%2Fwww.buergerkarte.at\
[12] %2Fnamespaces%2Fsecuritylayer%2F1.2%23%22+xmlns%3Adsig%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2F09\
[13] ....
[14] %3AXMLContent%3E%3C%2Fsl%3ABinaryFileData%3E%3C%2Fsl%3AInfoboxReadResponse%3E
3.2.4. First HTTP response form the DataURL to the CCE

The following block contains the first HTTP response form the application behind DataURL to the CCE. It contains the XML command CreateXMLSignature for signing a short HTML document (Login-token for Sign On).

[01] HTTP/1.1 307 Temporary Redirect
[02] Server: Apache-Coyote/1.1
[03] Set-Cookie: JSESSIONID=57B3767E23EB587AA8B0D013AE79DC52; Path=/SL12Tutorial/; HttpOnly
[04] Location: http://localhost:8080/SL12Tutorial/SignOn;jsessionid=E4C29CF18AA19126394243036318B88F;jsessionid=57B3767E23EB587AA8B0D013AE79DC52?use=done
[05] Content-Type: text/xml
[06] Content-Length: 611
[07] Date: Tue, 20 Mar 2012 08:18:06 GMT
[08]
[09] <?xml version='1.0' encoding='UTF-8'?>
[10] <sl:CreateXMLSignatureRequest xmlns:sl='http://www.buergerkarte.at/namespaces/securitylayer/1.2#'>
[11] <sl:KeyboxIdentifier>SecureSignatureKeypair</sl:KeyboxIdentifier>
[12] <sl:DataObjectInfo Structure='enveloping'>
[13] <sl:DataObject>
[14] <sl:XMLContent>Ich melde mich hiermit (20. 03. 2012 um 09:18:06 MEZ) zum Service XY an.</sl:XMLContent>
[15] </sl:DataObject>
[16] <sl:TransformsInfo>
[17] <sl:FinalDataMetaInfo>
[18] <sl:MimeType>text/plain</sl:MimeType>
[19] </sl:FinalDataMetaInfo>
[20] </sl:TransformsInfo>
[21] </sl:DataObjectInfo>
[22] </sl:CreateXMLSignatureRequest>
3.2.5. 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
3.2.6. 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).

3.2.7. 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>
3.2.8. Downloads for this example
3.2.9. Further information

Tabelle 13. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
OK OK OK OK OK OK

4. Specified but not frequently used commands

4.1. Verifying signatures

4.1.1. Verifying a signature in CMS format

4.1.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:DateTime>2012-06-25T00:00:00</sl:DateTime>
[05] <sl:CMSSignature>MIIHsAYJKoZIh...6kpOPJaLg==</sl:CMSSignature>
[06] </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>c

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

Tabelle 14. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK

4.1.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

Tabelle 15. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK

4.1.2. Verifying a signature in XML format

4.1.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="HS_signature" 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"/>
[12] <dsig:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1"/>
[13] <dsig:Reference Id="reference-data-0" URI="#signed-data-0">
[14] <dsig:Transforms>
[15] <dsig:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
[16] <xf2:XPath Filter="intersect"
[17] xmlns:xf2="http://www.w3.org/2002/06/xmldsig-filter2">
[18] id('signed-data-0')/node()</xf2:XPath>
[19] </dsig:Transform>
[20] </dsig:Transforms>
[21] <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[22] <dsig:DigestValue>7Dp/5KcvUfCnkohkOOzvFaeAIRc=</dsig:DigestValue>
[23] </dsig:Reference>
[24] ...
[25] </dsig:SignedInfo>
[26] <dsig:SignatureValue>...</dsig:SignatureValue>
[27] <dsig:KeyInfo>...</dsig:KeyInfo>
[28] <dsig:Object Id="signed-data-0">Ich bin ein einfacher Text.</dsig:Object>
[29] <dsig:Object Id="refetsi">...</dsig:Object>
[30] </dsig:Signature>
[31] </sl:XMLContent>
[32] </sl:SignatureEnvironment>
[33] <sl:SignatureLocation>/dsig:Signature</sl:SignatureLocation>
[34] </sl:SignatureInfo>
[35] </sl:VerifyXMLSignatureRequest>

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:SignatureEnvironment element (lines 6 to 32) 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.

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

Tabelle 16. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK

4.1.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/aktuell/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

Tabelle 17. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK

4.1.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

Tabelle 18. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK

4.1.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>Ich bin ein einfacher Text.</sl:XMLContent>
[051] </sl:Content>
[052] </sl:Supplement>c

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-Dokument</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

Tabelle 19. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK

4.2. Data encryption

4.2.1. Data encryption using the CMS standard

4.2.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

Tabelle 20. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED OK

4.2.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>

Line 2 contains the corresponding Security-Layer command.

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

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

Lines 35 to 37 contain meta information that is required for viewing the encrypted data.

Lines 40 to 48 contain the XML document that 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] <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 answer of the Security-Layer interface.

Line 3 contains the name declarations for the XML element within the response.

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

Lines 12 to 41 contain the RSA-encyrpted session key that is needed for the data encryption.

Lines 43 to 52 contain the XML document (base64-encoded) encrypted with the session key.

Downloads for this example
Further information

Tabelle 21. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED OK

4.2.2. Data encryption using the XML format

4.2.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

Tabelle 22. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED OK

4.2.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

Tabelle 23. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED OK

4.2.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.

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] <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

Tabelle 24. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED OK

4.3. Data decryption

4.3.1. Data decryption using the CMS standard

4.3.1.1. 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:Description>
[21] Diese Daten liegen als reiner Text vor.
[22] </sl:Description>
[23] </MetaInfo>
[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.


4.3.1.2. 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>
4.3.1.3. Downloads for this example
4.3.1.4. Further information

Tabelle 25. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED OK

4.3.2. Data decryption using the XML standard

4.3.2.1. 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 the element EncrElemsSelector to select the data which should be decrypted.

4.3.2.2. 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.

4.3.2.3. Downloads for this example
4.3.2.4. Further information

Tabelle 26. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED OK

4.4. Calculating the hash value

4.4.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.

4.4.1.1. 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/aktuell/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.

4.4.1.2. 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.

4.4.1.3. Downloads for this example

4.4.1.4. Further information

Tabelle 27. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED OK

4.5. Verifying the hash value

4.5.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.

4.5.1.1. Request

The following request is used by the Citizen Card Environment to request the verification of the hash values calculated in example 4.4.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] aktuell/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.

4.5.1.2. 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).

4.5.1.3. Downloads for this example

4.5.1.4. Further information

Tabelle 28. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED OK

4.6. Reading 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.

4.6.1. 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.

4.6.2. 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).

4.6.3. Downloads for this example

4.6.4. Further information

Tabelle 29. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED OK OK NOT IMPLEMENTED NOT IMPLEMENTED OK

4.7. 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.

4.7.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.

4.7.1.1. 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.

4.7.1.2. 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.

4.7.1.3. Downloads for this example
4.7.1.4. Further information

Tabelle 30. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED OK OK NOT IMPLEMENTED NOT IMPLEMENTED OK

4.7.2. Token state

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

4.7.2.1. 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.

4.7.2.2. 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.

4.7.2.3. Downloads for this example
4.7.2.4. Further information

Tabelle 31. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED OK OK NOT IMPLEMENTED NOT IMPLEMENTED OK

4.8. 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.

4.8.1. Downloads for this example

4.8.2. Further information

5 Further applications

5.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.

5.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.

5.1.1.1. 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="&lt;?xml version='1.0' encoding='UTF-8'?>&lt;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).

5.1.1.2. 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.

5.1.1.3. 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.

5.1.1.4. Downloads for this example
5.1.1.5. Further information

Tabelle 32. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
OK OK OK OK OK OK

5.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.

5.1.2.1. 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="&lt;?xml version='1.0' encoding='UTF-8'?>&lt;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/aktuell\
[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.

5.1.2.2. 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.

5.1.2.3. 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.

5.1.2.4. Downloads for this example
5.1.2.5. Further information

Tabelle 33. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK

5.2. Signing files

5.2.1. Signing a PDF document

This example shows a way to sign a PDF document by the citizen.

5.2.1.1. 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 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="urn:Document">
[06] <sl:Base64Content>JVB ... JSVFT0YK</sl:Base64Content>
[07] </sl:DataObject>
[08] <sl:TransformsInfo>
[09] <sl:FinalDataMetaInfo>
[10] <sl:MimeType>application/pdf</sl:MimeType>
[11] </sl:FinalDataMetaInfo>
[12] </sl:TransformsInfo>
[13] </sl:DataObjectInfo>
[14] </sl:CreateXMLSignatureRequest>

In line 6 the base64 encoded PDF document is embedded within the request. 

Line 10 contains the MimeType (application/pdf) so the Citizen Card Environment is able show the signature data in a correct way.

5.2.1.2. Response
We will not go into detail here. The answer should look something like the answer in section 2.1.1.2.
5.2.1.3. Downloads for this example
5.2.1.4. Further information

Tabelle 34. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
OK OK NOT IMPLEMENTED OK OK OK

6. 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.

6.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.

6.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>c

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>c

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 Subeitrag</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 Subeitrag</li>
[274] </ul>
[275] </li>
[276] </ul>
[277] </div>
[278] </body>
[279] </html>

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

6.2.1. Downloads for this example
6.2.2. Further information

6.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.

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

6.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.

6.3.1.1. 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.

6.3.1.2. 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).

6.3.1.3. Downloads for this example
6.3.1.4. Further information

Tabelle 35. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK

6.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.

6.3.2.1. 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.

6.3.2.2. Response

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

6.3.2.3. Downloads for this example
6.3.2.4. Further information

Tabelle 36. CCE support

Mobile Signature A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK

7. Overview CCE support

Tabelle 37. CCE support (Section 2, Frequently used interface commands)

Example Handy Signatur A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
Section 2.1.1, 'Initial Example' OK OK OK OK OK OK
Section 2.1.2, 'Creating a signature in xmldsig format' OK OK OK OK OK OK
Section 2.1.3, 'MOA-ID Request' OK OK OK OK OK OK
Section 2.1.4, 'Detached signature of a pdf document' OK OK NOT IMPLEMENTED OK OK OK
Section 2.3.1, 'Lesen der Personenbindung durch die Privatwirtschaft' OK OK OK OK OK OK
Section 2.3.2, 'Reading the SecureSignatureKeypair' OK OK OK OK OK OK
Section 2.4, 'Null-Operation' OK OK OK OK OK OK

Tabelle 38. CCE support (Section 3, Frequently used applications)

Example Handy Signatur A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
Section 3.1.1, 'Asynchronous user guidance using RedirectURL and DataURL' OK OK OK OK OK OK
Section 3.1.2, 'Synchronous user guidance using DataURL' OK OK OK OK OK OK
Section 3.1.3, 'Using forwarding parameters and forwarding headers' OK OK OK OK OK OK
Section 3.2, 'Transmitting a persons identity link and signing a document' OK OK OK OK OK OK

Tabelle 39. CCE support (Section 4, Specified but not frequently used commands)

Example Handy Signatur A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
Section 2.2.1, 'Initial Example' NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 2.2.2, 'Specifying data to be signed as reference' NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 4.1.1.1, 'Initial Example' NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 4.1.1.2, 'Extended Example' NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 4.1.2.1, 'Initial Example' NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 4.1.2.2, 'Extended Example' NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 4.1.2.3, 'Checking XMLDSIG manifests' NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 4.1.2.4, 'Supplementary objects' NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 4.2.1.1, 'CMS encryption using base64 encoded data' NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 4.2.1.2, 'CMS encryption using a reference' NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 4.2.2.1, 'Encryption of a complete XML document' NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 4.2.2.2, 'Encryption of an element within an existing XML document' NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 4.2.2.3, 'Encryption of the element content of an XML document' NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 4.3.1, 'Data decryption using the CMS standard' NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 4.3.2, 'Data decryption using the XML standard' NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 4.4.1, 'Initial example' NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 4.5.1, 'Initial example' NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 4.6, 'Reading available infoboxes' NOT IMPLEMENTED OK OK NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 4.7.1, 'Requesting properties' NOT IMPLEMENTED OK OK NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 4.7.2, 'Token state' NOT IMPLEMENTED OK OK NOT IMPLEMENTED NOT IMPLEMENTED OK

Tabelle 40. CCE support (Section 5, Further applications)

Example Handy Signatur A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
Section 5.1.1, 'Result as XML' OK OK OK OK OK OK
Section 5.1.2, 'Transformed result as HTML' NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 5.2.1, 'Signing a PDF document' OK OK NOT IMPLEMENTED OK OK OK

Tabelle 41. CCE support (Section 6, Standardised viewer format SLXHTML)

Example Handy Signatur A-Trust a.sign client 1.4.1.9 BDC HOTSign Mocca 1.3.15 online Mocca 1.3.15 local Trust Desk Basic 2.7.7
Section 6.3.1, 'Initial example' NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK
Section 6.3.2, 'Image data as supplementary object' NOT IMPLEMENTED NOT IMPLEMENTED OK NOT IMPLEMENTED NOT IMPLEMENTED OK