![]() |
Open
Interfaces for e-Government |
![]() |
Tutorial
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. |
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.
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.
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).
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
.
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 |
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>
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>
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 |
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.
[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.
[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>
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 |
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.
[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>
[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>
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 |
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.
[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).
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 |
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="https://sl.eid.egiz.gv.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.
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).
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 |
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.
[01] <?xml version="1.0" encoding="UTF-8"?>Line 4 contains the identifier of the info box to read (TutorialBinary).
[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>
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).
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"?>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).
[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>
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.
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 |
This example shows how to read the certificate according to
the SecureSignatureKeypair from the standardised Certificates
info box.
[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.
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
.
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 |
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.
[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.
[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.
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 |
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.
Beneath the XML-command request the following example will contain two additional form parameters:
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>Line 10 to 12 represents the form parameter DataURL, line 13 to 15 represent the form parameter RedirectURL.
[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>
\
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
\
character at the
end of a line) for better readability.
[01] HTTP/1.1 302 FoundAn HTTP Redirect (line 1 Code 302) was sent. The header Location contains the value from the form parameter RedirectURL.
[02] Location: http://localhost:8080/SL12Tutorial/Redirect;jsessionid=\
[03] 0D7EC8ECBDB4875E3B6D758A5615F178?use=redirecturl
[04] Content-Length: 0
\
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 OKThe 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.
[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>
\
character at the
end of a line) for better readability.
[01] POST /SL12Tutorial/Redirect;jsessionid=0D7EC8ECBDB4875E3B6D758A5615F178?use=dataurl HTTP/1.1As seen in line 1 it is an HTTP POST request.
[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
[01] HTTP/1.1 200 OKThis 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.
[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/>
\
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>
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 |
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:
DataURL
form parameter contains a URL of
the application server to which
the Citizen Card Environment
is to transmit the XML command response.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:
XMLRequest
(in this specific case
with the InfoBoxAvailable
command) and the additional form
parameter DataURL
.DataURL
which is part of the application. 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.
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
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
.
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.
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.
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 |
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.
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
).
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
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.
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.
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>
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 |
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:
DataURL
.DataURL
.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.
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
\
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
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>
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
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).
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>
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 |
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.
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.
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 |
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).
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.
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 |
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).
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.
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 |
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="https://sl.eid.egiz.gv.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).
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.
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 |
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).
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.
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 |
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.
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.
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 |
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
).
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.
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 |
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="https://sl.eid.egiz.gv.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.
[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.
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 |
New
)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:
sl:DataObject/sl:Base64Content)
sl:DataObject/sl:XMLContent
)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.
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.
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 |
Element
)
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.
[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.
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 |
ElementContent
)
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.
[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.
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 |
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.
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>
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 |
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.
[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.
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 |
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.
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="https://sl.eid.egiz.gv.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.
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
.
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 |
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.
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="https://sl.eid.egiz.gv.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.
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
).
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 |
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.
[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.
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).
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 |
The following examples show how to request the properties of the Citizen Card Environment and check the status of the Citizen Card token.
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.
[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.
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.
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 |
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.
[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.
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.
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 |
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.
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.
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.
Here you can see the HTML page with the form to be transmitted
to the Citizen Card Environment.
Please note that for better readability, the example has been formatted
and line breaks have been added (indicated by the \
character at the end of a line).
[01] <html>
[02] <head>
[03] <title>Direkte Ansteuerung</title>
[04] </head>
[05] <body>
[06] <p>Direktes Senden des Befehls <code>NullOperation</code>.</p>
[07] <form method="post" action="http://127.0.0.1:3495/http-security-layer-request">
[08] <input name="XMLRequest" type="hidden"
[09] value="<?xml version='1.0' encoding='UTF-8'?><NullOperationRequest \
[10] xmlns='http://www.buergerkarte.at/namespaces/securitylayer/1.2#'/>"/>
[11] <input type="submit" value="Request absenden"/>
[12] </form>
[13] </body>
[14] </html>
Lines 7 to 12 indicate the HTML form whose form data is to be
transmitted to the Citizen Card Environment
via HTTP POST (compare the method
attribute
in line 7) (compare the action
attribute in
line 7; http-security-layer-request
must
always be used in precisely this form (written this way) as a path
component in the URL).
Lines 8 to 10 contain the details of the XML interface
command. The name of the form element must always be XMLRequest
.
The value
attribute contains the XML
interface command; please note that escaping is required within the
attribute value, e.g. for the <
character (<
). Since the XML interface
command is not supposed to be visible to the citizen, the form element
has been defined as hidden (compare the type
attribute in line 8).
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.
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
.
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 |
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.
Here you can see the HTML page with the form to be transmitted
to the Citizen Card Environment.
Please note that for better readability, the example has been formatted
and line breaks have been added (indicated by the \
character at the end of a line).
[01] <html>
[02] <head>
[03] <title>Direkte Ansteuerung mit Stylesheet-Transformation</title>
[04] </head>
[05] <body>
[06] <p>Direktes Senden des Befehls <code>GetProperties</code> mit Stylesheet-\
[07] Transformation der Befehlsantwort.</p>
[08] <form method="post" action="http://127.0.0.1:3495/http-security-layer-request">
[09] <input name="XMLRequest" type="hidden"
[10] value="<?xml version='1.0' encoding='UTF-8'?><GetPropertiesRequest \
[11] xmlns='http://www.buergerkarte.at/namespaces/securitylayer/1.2#'/>"/>
[12] <input name="StylesheetURL" type="hidden"
[13] value="https://sl.eid.egiz.gv.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.
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.
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
.
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 |
This example shows a way to sign a PDF document by the citizen.
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.
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 |
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.
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.
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.
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.
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.
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="https://sl.eid.egiz.gv.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.
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="https://sl.eid.egiz.gv.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="https://sl.eid.egiz.gv.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).
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 |
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.
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.
The response from the Citizen Card Environment returns the same XML signature as the previous example and is therefore not explained further here.
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 |
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 |