Интерфейсът за комуникация с комуникационния клиент на ЕСОЕД дефинира една единствена операция – Submit. Тази операция има един входящ параметър от простия XSD тип string и един изходящ параметър, също от тип string. Стойностите на входящият и изходящият параметри представляват XML документ, чиято дефиниция е описана в следващите части на настоящия документ.
Стойностите на входящият и изходящият параметри на операцията Submit ще наричаме съобщения.
1.6Структура на XML документа предаван като параметър на операцията Submit
Предаваният XML документ има следната XSD schema, както и следните ограничения свързани с него:
В следващите секции на документа ще се разгледат поетапно елементите на тази схема.
1.6.1Описание на елемент „SenderDetails”
Заглавна част (Header) – попълва се от АИС на изпращащия участник на съобщението или от ЕСОЕД за съобщения от тип EsoedError и EsoedResponse. Състои се от следните части:
xMessageType – съдържа информация за типа (предназначението) на съобщението. Може да има някои от следните стойности:
Document – съобщение, което пренася документ създаден от АИС. Това е документът, който се пренася чрез ЕСОЕД.
DocumentReceipt – служебно съобщение, което се изпраща от АИС на получаващия участник като потвърждение, че пренасяният документ е получен успешно.
EsoedResponse – служебно съобщение, изпращано от комуникационния сървър към съответната АИС, за потвърждение на получаването на документ от ЕСОЕД.
EsoedError – съобщение, изпращано от комуникационния сървър към АИС, за възникнала грешка по време на преноса през ЕСОЕД. Описанието на грешката се намира в частта EsoedDetails.
EsoedSessionId – това поле е празно или съдържа идентификатор на сесия, генериран от ЕСОЕД. Когато АИС изпраща съобщение от тип документ това поле е празно. То се генерира и попълва от ЕСОEД и присъства във всички документи от тип EsoedError и EsoedResponse. АИС на получаващия участник е длъжен да го постави в DocumentReceipt. Всички съобщения, свързани с дадена сесия се идентифицират чрез полето EsoedSessionId. Ако то е празно, неговата стойност се взима от SessionID полето на елемента EsoedDetails. За разлика от EsoedCorrelationId, SessionId винаги трябва да е празно при стартиране на нов пренос от АИС. SessionId е идентификатор на преноса и не може да се дублира между различните преноси. Поради това, при съобщение от тип Document трябва да е празно и да се генерира от ЕСОЕД.
Correlation – съдържа информация, която се използва за корелация от АИС. Смисълът на тази информация е всяка АИС, която получава документ чрез ЕСОЕД, по нея да разбере този документ към кой предишен документ, преминал през ЕСОЕД, се отнася (например отговор към заявка). Този елемент представлява улеснение за участниците в ЕСОЕД. Всеки участник в ЕСОЕД е длъжен, когато получи документ през ЕСОЕД и генерира документ свързан с него, да копира всички данни от елемента Correlation. Полетата в този елемент са:
eServiceUri – съдържа УРИ на услугата, за която е съобщението
EsoedCorrelationID – Това поле е празно или съдържа идентификатора, генериран от ЕСОЕД, но попълнен от АИС на изпращащия участник на съобщението. Има няколко възможни сценария за това:
Когато съобщението съдържа първият подаден документ по дадена преписка (напр. заявка за използването на услуга), това поле се оставя празно
Когато съобщението е получено в АИС на участника (т.е. ЕСОЕД го е генерирал или пренесъл) и това поле е празно, то в елемента EsoedDetails\CorrelationID има попълнена стойност, и тази стойност се попълва от АИС в този елемент във всички бъдещи съобщения от тип документ, свързани с първоначалния документ
Когато елементът има стойност, тя се запазва от АИС във всички свързани съобщения от тип документ, които се изпращат през ЕСОЕД.
OriginatorExtraData – в това поле АИС на участника може да попълни допълнителна информация, която ще е полезна при получаване и идентифициране на документите, свързани с дадена заявка.
Sender – съдържа информация за участника, който изпраща съобщението или ЕСОЕД при съобщенията EsoedResponse и EsoedError.
DocumentURI – УРИ (от документния регистър на АИС-а) на пренасяният документ. Този елемент се попълва от АИС на участника при създаването на входящия параметър (съобщението) към операцията Submit, която е част от интерфейса на КК.
DocumentTypeURI – съдържа информация за УРИ на документа според регистъра на информационните обекти.
Authentication – съдържа цифровия подпис на участника. Подписът обхваща данните в заглавната част на съобщението и данните в елемента Body (по стандарта xmldsig). В този елемент като обект се съдържат и timestamp данните.
Recipient – съдържа информация за получаващия участник. Тази част съдържа само един елемент – УРИ на получаващия участник.
1.6.2Описание на елемент „EsoedDetails”
Детайли на ЕСОЕД (EsoedDetails) – попълва се и се подписва от ЕСОЕД. Този елемент съдържа служебна информация на ЕСОЕД. Тя се попълва, когато съобщение от тип документ преминава през ЕСОЕД или когато ЕСОЕД е източника на съобщението.
SessionId – Това поле съдържа идентификатор на сесия генериран от ЕСОЕД. Получаващият участник копира стойността му в SenderDetails в полето EsoedSessionId, когато изпраща техническо потвърждение за получен документ (DocumentReceipt).
CorrelationID - Това поле се попълва от ЕСОЕД при получаване на съобщение, което не съдържа стойност в EsoedCorrelationID (напр. при заявка за електронна услуга) и се използва във всички съобщения, касаещи тази заявка.
ReceiveTime – съдържа времето на получаване на съобщението от комуникационния сървър на ЕСОЕД.
Errors – тези данни се попълват при настъпване на грешка в ЕСОЕД (например при документ, който не отговаря на дефиницията в регистрите).
Authentication – съдържа подписа на ЕСОЕД (по стандарта xmldsig). В този елемент като обект се съдържат и timestamp данните.
AdditionalAttributes – съдържа допълнителна информация, добавена от ЕСОЕД. Не се използва от АИС на участниците.
1.6.3Тяло
Тяло (Body) – съдържа документа, предмет на пренос през ЕСОЕД. Комуникационния сървър на ЕСОЕД проверява структурата на този елемент спрямо регистъра на информационните обекти. Но ЕСОЕД не променя или интерпретира съдържанието на този елемент (съгл. Чл.6 от Наредбата за изискванията към ЕСОЕД).
1.6.4Цифров подпис
Съгласно чл. 22, ал.3 от Наредбата за ЕСОЕД всеки участник в обмена чрез своя комуникационен клиент, включително комуникационния сървър, подписва изпратените съобщения.
Схемата, в която се капсулират пренасяните документи, дефинира две места, в които се включват цифрови подписи:
В елемента SenderDetails
Подписът в този елемент се прави от изпращащия участник. Той трябва да включва елементите SenderDetails и Body.
В елемента EsoedDetails
Подписът в този елемент се прави от комуникационния сървър на ЕСОЕД при пренасяне на съобщението. Той трябва да включва елементите SenderDetails, EsoedDetails и Body.
Подписите се извършват по стандарта на W3 xmldsig (http://www.w3.org/2000/09/xmldsig# ). Върху стандарта са наложени някои допълнителни ограничения на използваните алгоритми, които са описани по-долу.
За да се опишат тези ограничения, разглеждаме следния пример (за улеснение всички base64 стойности са отрязани):
В SignedInfo елемента трябва да присъстват задължително:
Метод за канонизиране на SignedInfo елемента - http://www.w3.org/TR/2001/REC-xml-c14n-20010315
Метод за подписване - http://www.w3.org/2000/09/xmldsig#rsa-sha1
Reference елемент, с URI=”” (обхваща цялото съобщение)
В Reference елемента трябва да има следните трансформации:
Трансформация за вложен подпис - http://www.w3.org/2000/09/xmldsig#enveloped-signature
Трансформация, за дефиниране на елементите, които се подписват. Тук са възможни два варианта – за подписване от АИС на участника и за подписване от комуникационния сървър на ЕСОЕД
Трансформация за канонизиране на съдържанието, което се подписва - http://www.w3.org/TR/2001/REC-xml-c14n-20010315
Алгоритъмът за изчисляване на DigestValue трябва да е http://www.w3.org/2000/09/xmldsig#sha1.
Всеки подпис трябва да има добавен таймстам. За детайли виж т. 2.2.5 „Таймстамп”.
Трансформациите, описани по-горе, трябва да са същите при подписване на документите. Част от проверката на подписите е и проверка, че са използвани същите трансформации. Това включва и използваните префикси за namespace.
За да се гарантира еднозначно подписване и проверка се дефинират и някои правила за обработката на незначещи празни символи в XML съобщенията:
XML съобщенията не трябва да съдържат незначещи празни символи. Това включва форматиращи знаци, незначещи символи между тагове, които не са от тип string.
Всяка АИС по време на обработка на XML съобщение не трябва да добавя незначещи символи.
Нито един елемент в дефиницията на XML схемата не допуска наличие на т.н. смесено съдържание (mixed content). Точно казано един елемент не може да съдържа едновременно текст и други елементи. Това, в частност означава, че за незначещи празни символи се приемат всички празни символи между тагове, с изключение на елементите от тип string.
Налагането на тези правила е необходимо, тъй като канонизирането на XML документите не гарантира еднаква обработка на незначещите празни символи и различните платформи имат различни настройки по подразбиране за това.
1.6.5Таймстамп
Целта на включването на таймстамп към всеки цифров подпис е да се удостовери времето на подписване. Това става чрез т.нар. TSA (Time Stamp Authority) и Time Stamp Protocol (TSP, RFC 3161).Тъй като стандартът xmldsig не включва строго правило къде трябва да се запише Timestamp стойността, се използва елемента Object. Той е предвиден за включването на допълнителни данни към самия подпис, които може да не са включени в него.
За тази цел всеки от двата цифрови подписа в дадено съобщение трябва да има Object таг, чието ID е tsAis или tsEsoed в зависимост от това, дали подписа е на АИС, или на ЕСОЕД.
Съдържанието на този Object таг е един елемент Timestamp, който отговаря на следната схема:
В този елемент се записва base64 кодиран отговорът от TSA сървъра, точно както е получен.
Този отговор съдържа всичко необходимо, за да може да се удостовери времето на подписа.
Има няколко особености, които трябва да се имат предвид:
Данните, върху които се създава таймстамп, са стойността на SignatureValue елемента, като се взима не base64 кодирания низ, а стойността като байтов масив. Върху него се прилага хеш функцията (SHA1).
Nonce стойността се определя от всеки, който подписва. Тя не е необходима за проверката на таймстамп, тъй като присъства в отговора от TSA. Препоръката е да е случайно 64-битово число.
Публичната част на сертификата на TSA е необходима, за да се провери таймстампа. За да не се увеличава излишно обема на таймстамп елемента, тя не се включва в него. В отговора от TSA се съдържа серийния номер на използвания сертификат, както и издателя на сертификата. Всяко приложение, което иска да проверява таймстамп елементите трябва да има достъп до публичната част на съответния сертификат.
Като TSA сървър се ползва някой от сървърите на системата за единно време (СОЕВ).
1.6.6Криптиране
По изискване на „Наредба за изискванията към единната среда за обмен на електронни документи” (чл. 20 и чл. 22) всеки документ, който се пренася чрез ЕСОЕД се криптира с публичната част на сертификата на получателя (когато АИС на участник праща към ЕСОЕД, получател е комуникационният сървър на ЕСОЕД, когато комуникационният сървър на ЕСОЕД праща към АИС на участник, получател е АИС, когато КК генерира съобщение към АИС, получател е АИС на участник).
Криптирането се извършва по стандарта xmlenc (http://www.w3.org/2001/04/xmlenc#). Криптира се цялото пренасяно съобщение, като EncryptedData елемента се пренася като елемент в схемата на ЕСОЕД. За да е възможно това, схемата за съобщенията позволява вместо трите стандартни елемента SenderDetails, EsoedDetails и Body да има алтернативно един елемент EncryptedData, дефиниран в схемата на ЕСОЕД.
По-долу е даден пример за криптирано съдържание (отново за улеснение са съкратени всички base64 низове):
