Τεχνικές προδιαγραφές

Πρόσβαση στα εργαλεία του OOTShub.gr

Για να αποκτήσετε πρόσβαση στα εργαλεία τεχνικής υποστήριξης και συνεργασίας (wiki) της πλατφόρμας OOTShub.gr, θα πρέπει να δημιουργήσετε λογαριασμό.

Αποστείλετε στο email: a.liatou@mindigital.gr ή sdg-oots@mindigital.gr τα παρακάτω στοιχεία:

• Όνομα
• Επώνυμο
• Φορέας (π.χ. Υπουργείο Εσωτερικών)
• Email

και στελέχη του ΥΨΔ θα επικοινωνήσουν μαζί σας.

Υποβολή αιτήματος τεχνικής υποστήριξης

Αφού πρώτα έχετε αποκτήσει λογαριασμό στα εργαλεία υποστήριξης της πλατφόρμας OOTShub.gr, επιλέξτε «Τεχνική Υποστήριξη» και στην συνέχεια «Σύνδεση», όπου συμπληρώνετε τα στοιχεία πρόσβασης.

Επιλέξτε «Δημιουργία Νέου Αιτήματος» πάνω δεξιά και συμπληρώστε τα παρακάτω στοιχεία στην φόρμα αιτήματος:

• τίτλο,
• προτεραιότητα(χαμηλή, μέτρια, υψηλή),
• κατηγορία προβλήματος
  • Σύνδεση με Common Services,
  • Σύνδεση με κόμβους eIDAS,
  • Σύνδεση με Intermediary platform,
  • Αναφορά σφάλματος (λογισμικού/ λειτουργίας),
  • Ζήτημα ασφάλειας,
  • Άλλο
• περιγραφή του προβλήματος,

και επισυνάπτει τυχόν εικόνα ή έγγραφο.

Όταν ξεκινήσει η επεξεργασία του αιτήματος σας, θα αλλάξει η κατάσταση του «Σε εξέλιξη», ενώ θα ενημερωθείτε από την ομάδα υποστήριξης για τον τρόπο επίλυσης του προβλήματος που αντιμετωπίζετε.

Όταν ολοκληρωθεί και επιλυθεί το πρόβλημα το αίτημα θα κλείσει (κατάσταση αιτήματος «Κλειστό»), αλλά θα είναι διαθέσιμο προς παρουσίαση στη κεντρική οθόνη διαχείρισης, μαζί με όλη την επικοινωνία.

Επικαιροποίηση περιεχομένου στο wiki

Αφού πρώτα έχετε αποκτήσει λογαριασμό στα εργαλεία υποστήριξης της πλατφόρμας OOTShub, επιλέξτε «Εργαλείο συνεργασίας» και στην συνέχεια «Σύνδεση», όπου συμπληρώνετε τα στοιχεία πρόσβασης.

Μόλις συνδεθείτε αριστερά στο μενού εμφανίζεται η ανάλυση των Διαδικασιών και Απαιτήσεων Διαδικασιών που εμπλέκεται ο φορέας σας (π.χ. Υπ. Εσωτερικών).

Επιλέξτε την Διαδικασία ή Απαίτηση Διαδικασίας που θέλετε να επικαιροποιήσετε. Από το μενού πάνω δεξιά επιλέξτε «Επεξεργασία» και πραγματοποιήστε όποιες αλλαγές απαιτούνται.

Στην συνέχεια επιλέξτε «Αποθήκευση» για να αποθηκευτούν οι τροποποιήσεις και «Κλείσετε» για να κλείσει η επεξεργασία και να επανέλθετε στην αρχική σελίδα παρουσίασης της ανάλυσης.

Για την παρουσίαση των βασικών λειτουργειών του εν λόγω εργαλείου δημιουργήθηκε το παρακάτω βίντεο:

Video Project WIKI.mp4

Σύνδεση στην υπηρεσία αυθεντικοποίησης μέσω eIDAS

Τα βήματα επικοινωνίας και σύνδεσης με το eIDAS είναι τα ακόλουθα και αφορούν την υλοποίηση σε επίπεδο backend:

1. Γίνεται web service κλήση χρησιμοποιώντας τεχνολογία OPEN-ID σε .NET, με στόχο την επικοινωνία με την πλατφόρμα eIDAS. Μια τέτοια ενδεικτική κλήση είναι η ακόλουθη:

https://login.eidas.tech/auth/realms/eidas-proxy/protocol/openid-connect/auth?client_id=test-client&response_type=code&redirect_uri=https://oauth.pstmn.io/v1/callback&scope=openid profile email&state=random-state

στο πεδίο «redirect_uri» ορίζεται το αντίστοιχο url της εφαρμογής από την οποία θα γίνει η κλήση (στο παράδειγμα έχει οριστεί το url του postman)

2. Μετά την επιτυχή ολοκλήρωση της κλήσης, το eIDAS ανακατευθύνει τον χρήστη σε μια σελίδα, όπου ζητούνται πρόσθετες πληροφορίες και ολοκληρώνεται η σύνδεση με τον test user, επιστρέφοντας το ακόλουθο url:

https://oauth.pstmn.io/v1/callback?state=random-state&session_state=1e566be6-ea08-4e4c-91ee-9f3a25c6e70d&code=6d2bf2d3-1e79-4f17-adce-5ac51e9559a3.1e566be6-ea08-4e4c-91ee-9f3a25c6e70d.5bccfaff-9606-4e30-89be-0e27273b5317

στο πεδίο «code» είναι η παράμετρος που θα χρησιμοποιηθεί για τη λήψη του authentication token

3. Εκτελείται POST Request στο authentication token endpoint:

https://login.eidas.tech/auth/realms/eidas-proxy/protocol/openid-connect/token

με body:

• Το client_id που μας έχει κοινοποιηθεί από την αρχή διαχείρισης του eIDAS
• Το client_secret: που μας έχει κοινοποιηθεί από την αρχή διαχείρισης του eIDAS
• Το redirect_uri

Προσοχή: το redirect_uri θα πρέπει να έχει δηλωθεί στην αρχή διαχείρισης του eIDAS, αλλιώς η πρόσβαση ΔΕΝ θα επιτρέπεται.

• Τοgrant_type με το authorization_code

ΠΡΟΣΟΧΗ: Το code είναι εκείνο που λάβαμε στο προηγούμενο βήμα και το redirect_uri πρέπει να είναι ακριβώς το ίδιο με εκείνο που χρησιμοποιήθηκε στο αρχικό request.

Το αποτέλεσμα είναι να επιστραφεί ένα JSON response το οποίο περιλαμβάνει το authentication token που θα χρησιμοποιηθεί στις επόμενες κλήσεις επικοινωνίας με το eIDAS, με στόχο την αναγνώριση του συνδεδεμένου πολίτη.

Σημείωση: Για λόγους testing στο μη παραγωγικό περιβάλλον του eIDAS, δίνεται μια λίστα με test users (βλ. εικόνα παρακάτω), από τους οποίους μπορεί να επιλεγεί κάποιος με σκοπό να δοκιμαστεί η επιτυχής ολοκλήρωση της αυθεντικοποίησης μέσω eIDAS.

Σημειώνεται ότι θα πρέπει να γίνεται συχνός έλεγχος των ενεργών χωρών στις υπηρεσίες του eIDAS και να επικαιροποιείται η εφαρμογή ανάλογα. Στο παρακάτω link μπορείτε να δείτε την υπάρχουσα κατάσταση του δικτύου και να βρείτε στοιχεία επικοινωνίας με την εκάστοτε χώρα:

https://eidas.ec.europa.eu/efda/browse/notification/eid-chapter-contacts

Προετοιμασία πύλης διαδικασιών για την υποστήριξη διασύνδεσης με τις υπηρεσίες ΟΟΤS

Η πύλη διαδικασιών (procedure portals) του αρμόδιου φορέα θα πρέπει να επικαιροποιηθεί κατάλληλα, ώστε να υποστηρίξει την παροχή υπηρεσιών μέσω του OOTS στην Ελληνική και Αγγλική γλώσσα.

Συγκεκριμένα:

Α. Πύλη διαδικασιών πριν την αυθεντικοποίηση – Αρχική οθόνη

Ο αρμόδιος φορέα θα αναπτύξει/ επικαιροποιήσει την αρχική οθόνη της διαδικασίας, στην οποία ο χρήστης θα ενημερώνεται για τα οφέλη του OOTS και τη δυνατότητα απευθείας λήψης δικαιολογητικών που έχουν εκδοθεί σε άλλα κράτη-μέλη, με την προϋπόθεση σύνδεσης του μέσω συστήματος ηλεκτρονικής ταυτοποίησης eID. Θα δίνεται δυνατότητα  περαιτέρω ενημέρωσης χρηστών για το σύστημα OOTS μέσω σχετικού συνδέσμου στο OOTSHub (https://ec.europa.eu/digital-building-blocks/sites/display/OOTS/About+OOTS) ή στο Ελληνικό OOTSHub-Gr (https://ootshub.mindigital.gr/). Το λογότυπο του YourEurope θα πρέπει επίσης να φαίνεται στην οθόνη. Ενδεικτική εικόνα των παραπάνω πληροφοριών παρουσιάζεται παρακάτω:

Εικόνα 1 – Ενημέρωση για δυνατότητα χρήσης OOTS

Παράλληλα, στην αρχική οθόνη θα πρέπει να προσφέρεται δυνατότητα διασύνδεσης/ αυθεντικοποίησης των χρηστών μέσω εθνικής υποδομής (taxisnet), αλλά και μέσω Ευρωπαϊκού δικτύου eIDAS, καθώς μόνο μέσω πλαισίου eIDAS υπάρχει δυνατότητα χρήσης του OOTS προσφέροντας επαρκή επίπεδα ασφάλειας. Για καλύτερη κατανόηση αυτής της δυνατότητας από τους χρήστες προτείνεται η τοποθέτησης σημαίας δίπλα από κάθε επιλογή αυθεντικοποίησης eID, είτε μέσω εθνικής επιλογής, είτε Ευρωπαϊκής. Για την περίπτωση της χρήσης ευρωπαϊκής ψηφιακής ταυτότητας, προτείνεται να γράφεται «Συνέχεια με άλλο eID» δίπλα στην Ευρωπαϊκή σημαία. Στο παράδειγμα της εικόνας παρακάτω η εθνική επιλογή eID αφορά την Γερμανία. Επίσης, να προστεθεί υποστηρικτικό κείμενο κάτω από την επιλογή «Συνέχεια με άλλο eID» που θα αναφέρει «Ευρωπαϊκές χώρες συμπεριλαμβανομένων των ΕΟΧ (Ισλανδία, Λιχτενστάιν και Νορβηγία), και πολίτες που διαθέτουν ηλεκτρονική κάρτα διαμονής που έχει εκδοθεί από την ΕΕ/ΕΟΧ.», “European countries including EEA (Iceland, Liechtenstein and Norway), and citizens with an electronic residency card issued in the EU/EEA”.

Εικόνα 2 – Επιλογές διασύνδεσης στην πύλη διαδικασιών

Οι χρήστες θα πρέπει να ενημερώνονται ότι μόνο αν αυθεντικοποιηθούν μέσω eID θα μπορούν να χρησιμοποιήσουν το OOTS. Η χρήση αυθεντικοποίησης μέσω taxisnet δεν θα δίνει δυνατότητα χρήσης του OOTS (“Use digital identity log-in methods if you want to retrieve documents online”).

Β. Πύλη διαδικασιών  - οθόνη αυθεντικοποίησης μέσω δικτύου eIDAS

Εφόσον ο χρήστης επιλέξει αυθεντικοποίηση μέσω Ευρωπαϊκής ψηφιακής ταυτότητας (eID), ο Αρμόδιος φορέας θα αναπτύξει οθόνη η οποία θα παρουσιάζει λίστα χωρών με αλφαβητική σειρά, επιτρέποντας στο χρήστη να επιλέξει τη χώρα στην οποία έχει εκδοθεί το eID του. Για τις χώρες που δεν υποστηρίζουν την διαδικασία αυθεντικοποίησης μέσω δικτύου eIDAS, θα αναφέρεται ξεκάθαρα στην λίστα «Μη διαθέσιμη». Να παρέχετε υποστηρικτικό κείμενο που να περιγράφει τι πρέπει να κάνουν οι χρήστες, στην περίπτωση που η χώρα του δεν υποστηρίζει ακόμα την εν λόγω αυθεντικοποίηση όπως «Εάν η διασυνοριακή αυθεντικοποίηση δεν είναι διαθέσιμη ακόμα στην χώρα σας, παρακαλώ πηγαίνετε πίσω και επιλέξτε έναν άλλο τρόπο διασύνδεσης. Η χώρα σας θα παρέχει την υπηρεσία στο μέλλον», «If the cross-border authentication is not available yet for your country, please go back to the service and use another login method. Your country will become available in the future.».

Ενδεικτική εικόνα της οθόνης παρουσιάζεται παρακάτω:

Εικόνα 3 – Επιλογή χώρας έκδοσης eID χρήστη

Οι οδηγίες διασύνδεσης στην υποδομή eIDAS βρίσκονται στην περιγραφή «Σύνδεση στην υπηρεσία αυθεντικοποίησης μέσω eIDAS» παρακάτω.

Γ. Πύλη διαδικασιών - οθόνη μετά την αυθεντικοποίηση μέσω eIDAS

Μετά την επιτυχή αυθεντικοποίηση του χρήστη, ο Αρμόδιος φορέα θα πρέπει να αναπτύξει οθόνη στην οποία για κάθε διαδικασία που προσφέρεται, θα αναφέρονται οι απαιτήσεις διαδικασιών (procedure requirements) που απαιτούνται για την ολοκλήρωση της (π.χ. αποδεικτικό απολυτήριου δευτεροβάθμιας εκπαίδευσης). Θα πρέπει επίσης να αναφέρεται σε ποιες γλώσσες θα γίνονται αποδεκτά τα δικαιολογητικά αυτά, όπως Ελληνικά και Αγγλικά, ώστε να είναι ενήμεροι οι χρήστες. Όπως φαίνεται και στην ενδεικτική οθόνη παρακάτω, θα δίνεται δυνατότητα στους χρήστες να υποβάλλουν το απαιτούμενο δικαιολογητικό (αν το έχουν διαθέσιμο - upload) ή να χρησιμοποιήσουν το OOTS για να το εντοπίσουν σε άλλο κράτος-μέλος (retrieve online).

Εικόνα 4 – Δικαιολογητικά που ζητούνται για ολοκλήρωση της διαδικασίας

Στην περίπτωση που οι χρήστες επιλέξουν τη χρήση του συστήματος OOTS (retrieve online), θα προωθούνται στην ενδιάμεση πλατφόρμα (intermediary platform) που θα τους ενημερώνει ότι θα υποστηρίξει τον εντοπισμό και την ανάκτηση των αποδεικτικών που απαιτούνται, απευθείας από αρμόδιες δημόσιες αρχές άλλου κράτους-μέλους. Ο Αρμόδιος φορέας θα αναλάβει να διασυνδέσει την πύλη διαδικασιών με την ενδιάμεση πλατφόρμα και να προωθήσει τα στοιχεία του χρήστη και την εκάστοτε απαίτηση διαδικασιών (π.χ. απολυτήριο δευτεροβάθμιας εκπαίδευσης) στην ενδιάμεση πλατφόρμα.

Διασύνδεση φορέα στις υπηρεσίες του συστήματος OOTS μέσω ενδιάμεσης πλατφόρμας (intermediary platform)

Γενική περιγραφή

Το σύστημα «μόνον άπαξ» (Once Only Technical System - OOTS) έχει σαν στόχο να συνδέσει ψηφιακά τις δημόσιες διοικήσεις της Ε.Ε. και να επιτρέπει την ασφαλή και απευθείας διαβίβαση εγγράφων/ ανταλλαγή δικαιολογητικών πολιτών μεταξύ κρατών-μελών της Ε.Ε., εξαλείφοντας τα εμπόδια κινητικότητας διασυνοριακών χρηστών.  Το πεδίο εφαρμογής του OOTS και το νομοθετικό πλαίσιο είναι διαθέσιμα εδώ, ενώ τα οφέλη των πολιτών από τη χρήση του συστήματος περιγράφονται εδώ.

Ο κύριος ρόλος του OOTS είναι να διασφαλίσει ότι, όταν ένας χρήστης ζητά την ανάκτηση αποδεικτικών στοιχείων από άλλο κράτος-μέλος στο πλαίσιο μιας διαδικτυακής διαδικασίας, η πύλη διαδικασιών (procedure portal) θα εντοπίζει τους κατάλληλους παρόχους δικαιολογητικών (evidence providers), σε άλλο κράτος-μέλος, με τους κατάλληλους τύπους δικαιολογητικών, για να ικανοποιούνται οι απαιτήσεις της διαδικασίας (procedure requirements).

Αρχιτεκτονική & ταξίδι χρήστη

Για την πραγματοποίηση αυτής της ανταλλαγής δικαιολογητικών μεταξύ κρατών-μελών το OOTS έχει καθορισμένη αρχιτεκτονική, όπως παρουσιάζεται στην σελίδα «Αρχιτεκτονική» με συγκεκριμένες δομικές μονάδες (π.χ. κοινές υπηρεσίες (common services), ενδιάμεση πλατφόρμα (intermediary platform), σημεία πρόσβασης eDelivery κλπ).

Για την ολοκλήρωση μιας επιγραμμικής διαδικασίας μέσω OOTS, ο διασυνοριακός χρήστης ακολουθεί τα παρακάτω επτά (7) βήματα:

1. Αυθεντικοποίηση: Ο χρήστης αυθεντικοποιείται μέσω του συστήματος ηλεκτρονικής ταυτοποίησης eID (Κανονισμός EE 910/2014 - eIDAS)
2. Εντοπισμός δικαιολογητικών: Η πύλη διαδικασιών προσδιορίζει μέσα από την αλληλεπίδραση με τις Κοινές Υπηρεσίες του OOTS, τι πρέπει να ζητηθεί (τον τύπο δικαιολογητικών) και από ποιον πρέπει να ζητηθεί (πάροχο δικαιολογητικών).
3. Αίτημα δικαιολογητικών: Το αίτημα για το δικαιολογητικό αποστέλλεται στον κατάλληλο πάροχο δικαιολογητικών.
4. Ανακατεύθυνση: Ο χρήστης ανακατευθύνεται στην πλευρά του παρόχου δικαιολογητικών.
5. Προεπισκόπηση: Ο χρήστης κάνει προεπισκόπηση του δικαιολογητικού
6. Προώθηση δικαιολογητικών: Ο πάροχος δικαιολογητικών ανταποκρίνεται στο αίτημα για το δικαιολογητικό
7. Υποβολή: Ο χρήστης λαμβάνει το δικαιολογητικό και ολοκληρώνει επιγραμμικά την διαδικασία.

Αναλυτική παρουσίαση του user journey είναι διαθέσιμο εδώ.

Ακολουθούν τα βήματα που πρέπει να πραγματοποιήσει ο αρμόδιος φορέας, ώστε να συνδεθεί στις υπηρεσίες του OOTS με χρήση της ενδιάμεσης πλατφόρμας (intermediary platform).

A.    Επικαιροποίηση πύλης διαδικασιών (UI/UX)

Η πύλη διαδικασιών (procedure portals) του αρμόδιου φορέα θα πρέπει να επικαιροποιηθεί κατάλληλα, ώστε να υποστηρίξει την παροχή υπηρεσιών μέσω του OOTS στην Ελληνική και Αγγλική γλώσσα.

Οι προτεινόμενες παρεμβάσεις και καλές πρακτικές παρουσιάζονται αναλυτικά στις Τεχνικές προδιαγραφές και την επιλογή «Προετοιμασία πύλης διαδικασιών για την υποστήριξη διασύνδεσης με τις υπηρεσίες ΟΟΤS».

B.     Διασύνδεση στην υποδομή eIDAS & στην ενδιάμεση πλατφόρμα

Ακολουθήστε τις οδηγίες και διασυνδέστε την πύλη διαδικασιών (procedure portal) του φορέα σας με την υποδομή του δικτύου eIDAS, όπως παρουσιάζονται αναλυτικά στις Τεχνικές προδιαγραφές και την επιλογή «Σύνδεση στην υπηρεσία αυθεντικοποίησης μέσω eIDAS».  Ο χρήστης της διαδικασίας για να χρησιμοποιήσει τις υπηρεσίες του OOTS θα πρέπει να αυθεντικοποιηθεί με χρήση της ευρωπαϊκής ψηφιακής ταυτότητας του (eID User Login).

Γ. Διασύνδεση στην ενδιάμεση πλατφόρμα (intermediary platform)

Η Ελληνική υλοποίηση του OOTS έχει αναπτύξει ενδιάμεση πλατφόρμα (intermediary), η οποία πραγματοποιεί όλη την επικοινωνία με τις κοινές υπηρεσίες του OOTS και την υποδομή του eDelivery, προς διευκόλυνση των αρμοδίων φορέων για την διασύνδεση τους με τις υπηρεσίες του OOTS.

Τα βήματα διασύνδεσης στην ενδιάμεση πλατφόρμα περιγράφονται ακολούθως:

1. Κλήση προς το REST API της ενδιάμεσης πλατφόρμας

Για όλες τις κλήσεις προς το REST API χρησιμοποιείται BASIC Authentication με χρήση username και password. Τα στοιχεία πρόσβασης θα σας σταλούν μετά από επικοινωνία με το Υπουργείο.

2. [Προεραιτικό βήμα] Εύρεση κωδικού αποδεικτικού (requirement ID) για την διαδικασία που χρησιμοποιεί η πύλη διαδικασιών

Ο τρόπος εύρεσης του κωδικού του αποδεικτικού (requirement ID), ο οποίος είναι απαραίτητος για την κλήση προς την ενδιάμεση πλατφόρμα παρουσιάζεται ο αναλυτικά στις Τεχνικές προδιαγραφές και την επιλογή «Εύρεση κωδικού αποδεικτικού (requirement ID)»

3. «Handshake», απόκτηση νέου αναγνωριστικού αιτήματος φορέα (authority request ID) & επικοινωνία με την ενδιάμεση πλατφόρμα

Η εφαρμογή καλεί το κατάλληλο API της ενδιάμεσης πλατφόρμας, Landing Page Service URL μέσω HTTP POST και χρησιμοποιεί request body σε JSON μορφή, με τα παρακάτω metadata.

HTTP POST https://testnew.gsis.gr/dsae2/oots/rs/authority/handshake

Σημείωση:

Οι υποχρεωτικές παράμετροι κατά την κλήση είναι οι authorityId, authorityReturnUrl, procedureCode & requirementId. Οι παράμετροι που αφορούν στον χρήστη του Φορέα δεν είναι υποχρεωτικές. Αν δεν δοθούν, τότε με τη μετάβαση στο Intermediary Platform ο χρήστης θα γίνει redirected στη σελίδα του eIDAS για να κάνει login.

Η παροχή στοιχείων για τον χρήστη σηματοδοτείται από την ύπαρξη της παραμέτρου userEidasLoginLevelOfAssurance.

Αν υφίσταται η παράμετρος userEidasLoginLevelOfAssurance, τότε είναι υποχρεωτική η παροχή και των εξής παραμέτρων: userEidasId, userFamilyName, userGivenName, userDateOfBirth.

Παράδειγμα JSON Request Body:

{

"authorityId":"1007.907.0001",

"authorityReturnUrl":" https://mydomain.gr/<somepath>""procedureCode":"V2",

"requirementId":"https://sr.oots.tech.ec.europa.eu/requirements/8863718d-d7b9-3e10-8e66-ee1748b86fbb"

"authorityId":"1007.907.0001",

"authorityReturnUrl":"https://testnew.gsis.gr/dsae2/oots-authority/main.xhtml",

"procedureCode":"V2",

"requirementId":"https://sr.oots.tech.ec.europa.eu/requirements/8863718d-d7b9-3e10-8e66-ee1748b86fbb"

}

To API επιστρέφει το request URL, που θα χρησιμοποιηθεί στο επόμενο βήμα, μαζί με το authorityRequestId που προσδιορίζει μοναδικά το συγκεκριμένο request.

Παράδειγμα JSON Response:

{

"authorityRequestId": "4455251a-1c45-4e41-92e2-a65c77fe6dec",

"ootsRequesterUrl": "https://testnew.gsis.gr/dsae2/oots/requester.xhtml"

}

4. Ανακατεύθυνση στο Greek OOTS Intermediary Platform

Η εφαρμογή του Φορέα ανακατευθύνει τον χρήστη στο παρακάτω URL, το οποίο ελαβε στο προηγούμενο response (ootsRequesterUrl), βάζοντας ως query parameter το authorityRequestId που έλαβε από το βήμα 2.

HTTP GET https://testnew.gsis.gr/dsae2/oots/requester.xhtml

Query Parameter: authority-request-id

Παράδειγμα: https://testnew.gsis.gr/dsae2/oots/requester.xhtml?authority-request-id=4455251a-1c45-4e41-92e2-a65c77fe6dec

Ο χρήστης περιηγείται στο Intermediary Portal ακολουθώντας τις ενδεικτικές οδηγίες για την εύρεση αποδεικτικού με χρήστη των υπηρεσιών του OOTS.

5. Λήψη απαιτούμενο αποδεικτικό

Όταν τελειώσει η αλληλεπίδραση με τις υπηρεσίες του OOTS και ο χρήστης επιλέξει τα έγγραφα που θέλει να ανακτήσει, το Greek OOTS Intermediary Platform κάνει επαναπροώθηση (redirect) στο «authorityReturnUrl» και επιστρέφει το χρήστη στη σελίδα που έχει υποδείξει ο Φορέας στην πρώτη REST κλήση (handshake).

Έχοντας επιστρέψει στη σελίδα του Φορέα, ο Φορέας πραγματοποιεί HTTP POST request στο παρακάτω URL με body (ως text/plain) το authorityRequestId.

HTTP POST https://testnew.gsis.gr/dsae2/oots/rs/authority/evidences

Επιστρέφεται ένα JSON Response που περιέχει μια λίστα με τα evidence JSON objects. Ανάλογα με τη χώρα καθώς και το requirement και την ζητούμενη διαδικασία, η λίστα μπορεί να περιέχει ένα ή παραπάνω evidences.

Κάθε evidence περιέχει τα πεδία:

• title (Τίτλος του εγγράφου)
• mimeType (Τύπος του εγγράφου π.χ. PDF, XML κ.α.)
• base64Content (Το περιεχόμενο του εγγράφου κωδικοποιημένο σε base64)

Η εφαρμογή το Φορέα είναι υπεύθυνη για το parsing του κάθε evidence JSON object.

Παράδειγμα JSON Response:

[{

"title": "Proof of vehicle registration",

"mimeType": "application/xml",

"base64Content": "PEF…RlbmNlPg=="

}]

Σημείωση: Για να δοκιμαστεί η επιτυχής επικοινωνία με την ενδιάμεση πλατφόρμα με χρήση του eIDAS, θα χρειαστεί να χρησιμοποιήσετε έναν eIDAS χρήστη που είναι ενεργός τόσο στη χώρα αυθεντικοποίησης (π.χ. Ελλάδα), όσο και στην χώρα από την οποία ζητείται το εκάστοτε δικαιολογητικό (π.χ. Κύπρος). Για πιο άμεσο testing που αφορά μόνο την αλληλεπίδραση με το OOTS μπορείτε να παρακάμψετε το eIDAS login, δοκιμάζοντας την επικοινωνία με έναν δοκιμαστικό χρήστη που προσφέρεται από τον κάθε πάροχο (π.χ. από την Κύπρο). Για περισσότερες πληροφορίες σχετικά με τους δοκιμαστικούς χρήστες ανά χώρα και ανά περίπτωση:

• Αν ο φορέας σας έχει πρόσβαση στο wiki που διατηρεί η ΕΕ ακολουθήστε το παρακάτω σύνδεσμο, όπου θα βρείτε πληροφορίες για τους test users και τα requirements που υποστηρίζει η κάθε χώρα, καθώς και το στάδιο υλοποίησής τους): https://ec.europa.eu/digital-building-blocks/wikis/pages/viewpage.action?spaceKey=SDGOO&title=Find+a+testing+partner+-+TD
• Αν δεν έχετε πρόσβαση στο wiki που διατηρεί η ΕΕ, επικοινωνήστε με το Υπουργείο Ψηφιακής Διακυβέρνησης στο παρακάτω email: sdg-oots@mindigital.gr

Επίσης, στον παρακάτω σύνδεσμο μπορείτε να βρείτε πληροφορίες για το σύνολο των παρεχόμενων διαδικασιών (procedures) και αποδεικτικών (requirements) ανά χώρα και ανά φορέα και σε ποιο στάδιο ετοιμότητας βρίσκονται (Draft, In review, Published): https://oots.pages.code.europa.eu/evidence-explorer/ee-app/#/home

Eύρεση κωδικού αποδεικτικού (Requirement ID)

Για να το προσδιορίσετε τον κωδικό του αποδεικτικού (requirement ID), ο οποίος είναι απαραίτητος για την κλήση προς την ενδιάμεση πλατφόρμα χρησιμοποιείστε τον παρακάτω σύνδεσμο: https://testnew.gsis.gr/dsae2/oots-authority

Στο πρώτο drop-down-list με τον τίτλο "Επιλογή διαδικασίας", επιλέγετε η διαδικασία που προσφέρεται από την πύλη διαδικασιών (procedure portal) και έχει μπροστά έναν αλφαριθμητικό κωδικό όπως R1, S1, T1, T2 κλπ.

Με την επιλογή διαδικασίας, αυτόματα συμπληρώνεται το δεύτερο drop-down-list με τον τίτλο "Επιλογή απαίτησης", με όλες τις απαιτήσεις διαδικασιών (procedure requirements) που είναι σχετικές με την επιλεχθείσα διαδικασία. Επιλέγοντας μια απαίτηση, ο χρήστης μπορεί να δει τον κωδικό της, με τον τίτλο "requirement id".

Π.χ. Διαδικασία V2 - Registering a motor vehicle originating from or already registered in a Member State, in standard procedures (Ταξινόμηση μηχανοκίνητου οχήματος που προέρχεται από κράτος μέλος ή που έχει ήδη ταξινομηθεί σε κράτος μέλος, κατά τις τυπικές διαδικασίες) και απαίτηση διαδικασίας Proof of vehicle registration Part I (with the optional II.6 C.2 vehicle owner information included) (άδεια κυκλοφορίας), με κωδικό requirement ID https://sr.oots.tech.ec.europa.eu/requirements/ff8919ba-740b-3ec3-bbe4-15f9ace4ca41.

Eισαγωγή

Το Once-Only Technical System (OOTS) είναι μια διακρατική υποδομή που επιτρέπει την ασφαλή ανταλλαγή επίσημων εγγράφων (evidences) ανάμεσα σε αρχές διαφορετικών κρατών-μελών της ΕΕ. Με άλλα λόγια, πολίτες και επιχειρήσεις μπορούν να ζητούν και να λαμβάνουν ηλεκτρονικά πιστοποιητικά από άλλες χώρες, αποφεύγοντας την επανυποβολή δεδομένων που υπάρχουν ήδη αλλού. Το OOTS αξιοποιεί το ευρωπαϊκό δίκτυο eDelivery ως κανάλι μεταφοράς, προσφέροντας ασφαλή και διαλειτουργική ανταλλαγή μηνυμάτων μεταξύ οργανισμών. Η επίσημη λύση eDelivery Access Point της ΕΕ είναι το λογισμικό Domibus, το οποίο υλοποιεί το πρωτόκολλο AS4 (ebMS3 πάνω από SOAP με WS-Security) για ασφαλή ανταλλαγή επιχειρησιακών μηνυμάτων. Στην πράξη, το Domibus θα μεταφέρει τα XML αιτήματα και τις απαντήσεις μεταξύ των κρατών.

Οι παρούσες οδηγίες στοχεύουν σε προγραμματιστές που υλοποιούν έναν Evidence Requester, δηλαδή μια εφαρμογή που ζητά στοιχεία/έγγραφα από άλλες χώρες (όχι έναν πάροχο). Σημειώνεται ότι η πιστοποίηση χρηστών μέσω eIDAS (διασυνοριακή ταυτοποίηση) θεωρείται προαπαιτούμενη και υλοποιείται ξεχωριστά – εδώ απλώς αναφέρεται για το πλαίσιο, αλλά δεν καλύπτεται λεπτομερώς. Στην υλοποίηση που ακολουθεί, υποθέτουμε ότι ο τελικός χρήστης έχει ήδη αυθεντικοποιηθεί μέσω eIDAS και ότι η εφαρμογή καταναλώνει τα Common Services του OOTS, χωρίς να τα υλοποιεί η ίδια.

Δομή και αρχιτεκτονική του OOTS

Το OOTS αποτελείται από τρεις βασικούς πυλώνες που συνεργάζονται για την ανταλλαγή των εγγράφων:

• Evidence Broker (EB): Υπηρεσία καταλόγου που δημοσιεύει ποιοι τύποι εγγράφων (evidence types) μπορούν να χρησιμοποιηθούν ως αποδεικτικά για συγκεκριμένες απαιτήσεις διαδικασιών στα κράτη-μέλη. Με βάση προδιαγεγραμμένους συσχετισμούς μεταξύ απαιτήσεων και πιθανών τύπων εγγράφων, το EB βοηθά στον εντοπισμό του κατάλληλου εγγράφου που αποδεικνύει ότι ο χρήστης πληροί μια συγκεκριμένη απαίτηση διαδικασίας.
• Data Service Directory (DSD): Υπηρεσία μητρώου παρόχων που επιτρέπει στον Evidence Requester να βρει όλες τους διαθέσιμους παρόχους (Data Services) σε ένα συγκεκριμένο κράτος, οι οποίοι μπορούν να προσφέρουν τον ζητούμενο τύπο εγγράφου. Εντοπίζει δηλαδή ποιοι οργανισμοί/αρμόδιες αρχές ενός κράτους-μέλους παρέχουν το συγκεκριμένο πιστοποιητικό.
• AS4 Gateway (Domibus): Η πύλη ανταλλαγής μηνυμάτων που διαχειρίζεται την ασφαλή μεταφορά των αιτημάτων και απαντήσεων μεταξύ των κρατών μέσω του πρωτοκόλλου AS4 (eDelivery). Κάθε χώρα διαθέτει ένα (ή παραπάνω) σημείο πρόσβασης (Access Point) όπως το Domibus, το οποίο αναλαμβάνει τη δρομολόγηση των μηνυμάτων προς το αντίστοιχο σημείο του άλλου κράτους.

Σημείωση: Οι Evidence Broker και Data Service Directory αποτελούν τα κεντρικά Common Services που παρέχει η Ευρωπαϊκή Επιτροπή, ενώ το AS4 Access Point είναι ευθύνη κάθε κράτους-μέλους. Περισσότερες πληροφορίες για την αρχιτεκτονική και τις επαναχρησιμοποιούμενες υπηρεσίες του OOTS μπορείτε να βρείτε στον επίσημο κατάλογο της Ευρωπαϊκής Επιτροπής.

Προαπαιτούμενα

Πριν ξεκινήσει η ενσωμάτωση, βεβαιωθείτε ότι διαθέτετε τα παρακάτω:

• Πρόσβαση σε Domibus gateway: Ένα dedicated Access Point (Domibus ή άλλο συμβατό λογισμικό eDelivery) είτε εγκατεστημένο εντός του φορέα σας είτε παρεχόμενο κεντρικά. Θα χρειαστείτε πιθανώς URL υπηρεσιών (WSDL file), διαπιστευτήρια πρόσβασης (π.χ. certificate ή χρήστη/κωδικό) και ρυθμίσεις ασφαλείας για το Domibus του περιβάλλοντός σας. Παράδειγμα ενός wsdl file θα βρείτε εδώ: https://ootshub.mindigital.gr/domibus/services/wsplugin?wsdl.
• Βάση δεδομένων: Για την παρακολούθηση των αιτημάτων και των απαντήσεων. Το σύστημά σας θα πρέπει να καταγράφει τουλάχιστον το μοναδικό αναγνωριστικό κάθε αιτήματος (Message ID / Conversation ID) και την κατάστασή του (π.χ. pending, completed).
• Χώρο αποθήκευσης αρχείων: Σε περίπτωση που τα παραλαμβανόμενα αποδεικτικά είναι αρχεία (π.χ. PDF), θα χρειαστεί αποθήκευση σε ασφαλές αποθετήριο (π.χ. Amazon S3, Azure Blob Storage, Alfresco, MinIO ή άλλο).
• Ολοκληρωμένη eIDAS σύνδεση: Όπως προαναφέρθηκε, η αυθεντικοποίηση του χρήστη μέσω eIDAS πρέπει να έχει υλοποιηθεί στην εφαρμογή. Το σύστημά θα πρέπει να διαθέτει τα απαραίτητα στοιχεία ταυτοποίησης του χρήστη (π.χ. χώρα προέλευσης, όνομα, ημερομηνία γέννησης ή άλλα αναγνωριστικά) ώστε να τα χρησιμοποιήσει στο αίτημα προς τον πάροχο (service provider).

Βήμα 1 – Επικοινωνία με τα Common Services (EB & DSD)

Στο πρώτο στάδιο, η εφαρμογή θα επικοινωνήσει με τα Evidence Broker και Data Service Directory προκειμένου να βρει τι είδους έγγραφο χρειάζεται και ποιος φορέας μπορεί να το παρέχει, για μια συγκεκριμένη διοικητική διαδικασία.

Ορολογίες και βασικές έννοιες

• Procedure (Διαδικασία): μια συγκεκριμένη διοικητική διαδικασία (π.χ. έκδοση πιστοποιητικού γέννησης, ταυτοποίηση οχήματος). Κάθε διαδικασία έχει έναν μοναδικό πανευρωπαϊκό κωδικό procedureCode. Για παράδειγμα, το R1 αντιστοιχεί στη διαδικασία αίτησης πιστοποιητικού γέννησης και το V2 σε διαδικασία σχετική με οχήματα (Vehicle Procedure). Κάθε κράτος-μέλος έχει ορίσει τις διαδικασίες του σε συνεργασία με την ΕΕ, χρησιμοποιώντας αυτούς τους κωδικούς. Εδώ θα βρείτε μια λίστα με τις δημοσιευμένες διαδικασίες: https://oots.pages.code.europa.eu/evidence-explorer/ee-app/#/procedures
• Requirement (Απαίτηση): μια ρητή απαίτηση μέσα σε μια διαδικασία – πρακτικά, απαντά στην ερώτηση «ποιο έγγραφο χρειάζομαι για αυτή τη διαδικασία;». Για παράδειγμα, σε μια διαδικασία εγγραφής νεογέννητου, ένα requirement μπορεί να είναι «απαιτείται πιστοποιητικό γέννησης του παιδιού». Κάθε requirement χαρακτηρίζεται μοναδικά από ένα requirementId (URI στο Semantic Repository).
• Evidence Type: μια πρότυπη κατηγορία εγγράφου, όπως birth-certificate, diploma, marriage-certificate κ.λπ. Ένα Evidence Type αντιπροσωπεύει μια συγκεκριμένη μορφή εγγράφου που μπορεί να ικανοποιήσει ένα requirement. Για παράδειγμα, για το requirement "πιστοποιητικό γέννησης", το αντίστοιχο evidence type θα μπορούσε να είναι ένα ηλεκτρονικό έγγραφο PDF με συγκεκριμένη δομή που περιέχει τα στοιχεία γέννησης. Κάθε evidence type έχει επίσης ένα μοναδικό αναγνωριστικό (URI στο Semantic Repository, συχνά ονομαζόμενο evidenceTypeClassification).

Endpoints των Common Services

Η επικοινωνία με τον Evidence Broker και το DSD γίνεται μέσω προκαθορισμένων REST endpoints (HTTP GET requests). Αυτά ήδη φιλοξενούνται από την Ευρωπαϊκή Επιτροπή, οπότε δεν χρειάζεται δική σας υλοποίηση – απλώς θα τα καταναλώσετε. Τα βασικά endpoints είναι:

• EB1 – Get Requirements: Επιστρέφει τη λίστα των απαιτήσεων (Requirements) για μια δεδομένη διαδικασία και χώρα.
  GET https://query.cs.oots.tech.ec.europa.eu/eb/rest/search
  Query parameters:
  • queryId = urn:fdc:oots:eb:ebxml-regrep:queries:requirements-by-procedure-and-jurisdiction
  • procedure-id = κωδικός διαδικασίας (π.χ. R1)
  • country-code = κωδικός χώρας (ISO 3166-1 alpha-2, π.χ. CY για Κύπρο)

• Λειτουργία: Το EB λαμβάνει το αίτημα και ελέγχει αν υπάρχουν καταχωρημένες απαιτήσεις για τη συγκεκριμένη διαδικασία σε αυτό το κράτος. Για παράδειγμα, ένα αίτημα:
• .../eb/rest/search?queryId=...requirements-by-procedure-and-jurisdiction&procedure-id=R1&country-code=DE
• θα αναζητήσει όλες τις απαιτήσεις του DE (Γερμανία) για τη διαδικασία R1 (αίτηση πιστοποιητικού γέννησης). Σε περίπτωση επιτυχίας, επιστρέφει μια λίστα με 0 ή περισσότερα αντικείμενα Requirement (μέσα σε ένα QueryResponse XML). Κάθε Requirement που επιστρέφεται περιέχει πληροφορίες όπως το μοναδικό του ID, την περιγραφή του και συνδέσεις προς σχετικά Evidence Types. (Εάν δεν βρεθεί σχετική απαίτηση, το EB επιστρέφει κατάλληλο μήνυμα λάθους Exception).
• Περισσότερες λεπτομέρειες εδώ.

• EB2 – Get Evidence Types: Επιστρέφει τους διαθέσιμους τύπους εγγράφων (Evidence Types) που αντιστοιχούν σε ένα συγκεκριμένο Requirement, εντός μιας συγκεκριμένης χώρας.
  GET https://query.cs.oots.tech.ec.europa.eu/eb/rest/search
  Query parameters:
  • queryId = urn:fdc:oots:eb:ebxml-regrep:queries:evidence-types-by-requirement-and-jurisdiction
  • requirement-id = το ID του requirement που μας ενδιαφέρει (URI όπως επιστράφηκε από το EB1)
  • country-code = κωδικός χώρας (ISO 3166-1)

• Λειτουργία: Το EB λαμβάνει το requirementId και αναζητά ποιοι τύποι εγγράφων μπορούν να το ικανοποιήσουν. Εδώ το country-code χρησιμοποιείται για να φιλτραριστούν οι τύποι εγγράφων που έχουν καταχωρηθεί υπό συγκεκριμένη δικαιοδοσία – πρακτικά, δηλώνει από ποια χώρα θέλουμε να είναι το αποδεικτικό. Συνήθως, αν η διαδικασία εκτελείται στη χώρα Α και ο πολίτης χρειάζεται έγγραφο από χώρα Β, τότε σε αυτό το βήμα η χώρα που θα βάλουμε είναι η χώρα-πάροχος (Β). Για παράδειγμα, αν το requirement είναι "πιστοποιητικό γέννησης" και ο χρήστης έχει γεννηθεί στην Κύπρο, θα βάλουμε country-code=CY ώστε να πάρουμε τον τύπο εγγράφου όπως ορίζεται στην κυπριακή πλευρά. Το αποτέλεσμα είναι ένα QueryResponse με 0 ή περισσότερα Evidence Type αντικείμενα (τα οποία περιλαμβάνουν το evidenceTypeClassification ID τους). Κάθε evidence type ουσιαστικά αντιστοιχεί σε μια συγκεκριμένη μορφοποίηση εγγράφου που παρέχει κάποιος φορέας σε εκείνη τη χώρα.
• Περισσότερες λεπτομέρειες εδώ.

• DSD – Find Data Services: Επιστρέφει τους παρόχους (Access Services) που μπορούν να δώσουν ένα συγκεκριμένο evidence type σε μια χώρα.
  GET https://query.cs.oots.tech.ec.europa.eu/dsd/rest/search
  Query parameters:
  • queryId = urn:fdc:oots:dsd:ebxml-regrep:queries:dataservices-by-evidencetype-and-jurisdiction
  • evidence-type-classification = το ID του evidence type (URI όπως από το EB2)
  • country-code = κωδικός χώρας (ISO 3166-1) – η χώρα του παρόχου

• Λειτουργία: Δεδομένου ενός συγκεκριμένου τύπου αποδεικτικού και μιας χώρας, το DSD επιστρέφει όλες τις καταχωρημένες υπηρεσίες (data services) των αρμόδιων φορέων της χώρας αυτής, που μπορούν να παράσχουν το αποδεικτικό. Πρόκειται ουσιαστικά για τις διαθέσιμες υπηρεσίες Evidence Provider για το ζητούμενο έγγραφο. Συνήθως για κάθε evidence type ανά χώρα υπάρχει τουλάχιστον μία αντίστοιχη υπηρεσία (π.χ. η υπηρεσία του Ληξιαρχείου στην Κύπρο για το πιστοποιητικό γέννησης). Κάθε data service εγγραφή περιέχει πληροφορίες όπως το μοναδικό αναγνωριστικό του παρόχου ή/και το Participant ID του στο δίκτυο eDelivery, λεπτομέρειες για τα υποστηριζόμενα προφίλ δεδομένων και εκδόσεις (π.χ. αν ακολουθεί το μοντέλο δεδομένων OOTS-EDM v1.0 ή v1.2), κ.λπ. Αυτές οι πληροφορίες θα χρειαστούν για την δρομολόγηση του αιτήματος μέσω AS4.
• Περισσότερες λεπτομέρειες εδώ.

Σημαντικές Παρατηρήσεις:

• Περιβάλλον δοκιμών (UAT): Για δοκιμές σε περιβάλλον acceptance των Common Services, χρησιμοποιήστε τη διεύθυνση με cs.acc.oots.... Δηλαδή, προσθέτοντας acc μετά το cs στο base URL, π.χ. https://query.cs.acc.oots.tech.ec.europa.eu/.... Στο περιβάλλον αυτό μπορείτε να δοκιμάσετε χωρίς να επηρεάζεται η παραγωγική υπηρεσία.
• Documentation API: Αναλυτικές τεχνικές λεπτομέρειες για τα APIs των Common Services (μορφή των XML που επιστρέφονται, σχήματα κ.λπ.) μπορείτε να βρείτε στα Technical Design Documents (TDD) της Επιτροπής. Οι απαντήσεις των EB/DSD είναι σε μορφή ebXML QueryResponse (XML) και ακολουθούν συγκεκριμένα σχήματα που ορίζονται εκεί.
• Χρήση των αποτελεσμάτων: Αφότου λάβετε τα αποτελέσματα των παραπάνω κλήσεων, η εφαρμογή σας θα πρέπει να:

1. 1. EB1: Διαβάσει το Requirement ID που αντιστοιχεί στην απαίτηση της διαδικασίας. (Ενδέχεται να υπάρχουν πολλαπλά requirements – π.χ. περισσότερα του ενός έγγραφα απαιτούνται για μια διαδικασία – οπότε ίσως χρειαστεί να τα εμφανίσετε στον χρήστη ή να επιλέξετε ποιο θα ζητήσετε μέσω OOTS).
   2. EB2: Χρησιμοποιήσει το Requirement ID για να λάβει ένα ή περισσότερα Evidence Type IDs. Αν βρεθούν πολλαπλοί τύποι, μπορεί να χρειαστεί επιλογή. Συχνά όμως θα υπάρχει μόνο ένας κατάλληλος τύπος εγγράφου για ένα requirement σε συγκεκριμένη χώρα.
   3. DSD: Χρησιμοποιήσει το Evidence Type ID και τον κωδικό χώρας του παρόχου για να πάρει τις πληροφορίες του παρόχου (ή των παρόχων). Συνήθως θα λάβετε τουλάχιστον ένα identifier του φορέα-παρόχου που θα χρησιμοποιηθεί ως διεύθυνση προορισμού στο μήνυμα AS4.

Αφού συγκεντρωθούν τα παραπάνω στοιχεία (Requirement ID, Evidence Type ID, Provider’s identifiers), είστε έτοιμοι να κατασκευάσετε το ίδιο το evidence request.

Βήμα 2 – Προετοιμασία του Evidence Request (δημιουργία QueryRequest)

Το επόμενο βήμα είναι να δημιουργήσετε την κατάλληλη δομή δεδομένων αιτήματος (Evidence Request) και να τη μετατρέψετε σε μορφή ebXML RegRep 4.0 QueryRequest (που είναι η μορφή που αναμένει το σύστημα). Πρόκειται για ένα XML έγγραφο που περιλαμβάνει όλα τα απαιτούμενα στοιχεία του αιτήματος και συμμορφώνεται με το προφίλ του OOTS.

Κάθε QueryRequest XML πρέπει να περιέχει τα σωστά στοιχεία και να ακολουθεί συγκεκριμένη σειρά και ονοματολογία σύμφωνα με το σχήμα. Ενδεικτικά, το QueryRequest θα περιλαμβάνει μεταξύ άλλων:

• Μοναδικά IDs: Κάθε μήνυμα έχει ένα MessageID (μοναδικό αναγνωριστικό μηνύματος) και κάθε αίτημα ξεκινά μια συζήτηση με ένα ConversationID που θα συσχετίσει τις μετέπειτα απαντήσεις. Αυτά μπορούν να είναι τυχαία GUID/UUID.
• Στοιχεία αιτήματος: Την ταυτότητα του αιτούντος φορέα και του παρόχου (Party IDs για αποστολέα/παραλήπτη), τον τύπο υπηρεσίας και ενέργειας (Service/Action) που υποδηλώνουν ότι πρόκειται για αίτημα παροχής αποδεικτικού στοιχείου, καθώς και το payload του αιτήματος.
• Περιεχόμενο αιτήματος (Payload): Εδώ το payload θα είναι το Query που αποτελεί το πραγματικό ερώτημα για το έγγραφο. Το Query θα πρέπει να περιέχει:
  • Την πληροφορία για το ζητούμενο evidence, δηλ. τον τύπο evidence (EvidenceTypeClassification ID) που θέλουμε να λάβουμε.
  • Πληροφορίες για τον χρήστη ώστε ο πάροχος να εντοπίσει το σωστό αρχείο. Αυτό περιλαμβάνει τα στοιχεία ταυτοποίησης του ατόμου για το οποίο ζητείται το έγγραφο. Συχνά, βάσει του TDD, αυτά είναι συγκεκριμένα πεδία όπως ονοματεπώνυμο, ημερομηνία γέννησης, ή/και κάποιο εθνικό αναγνωριστικό εφόσον υπάρχει, δομημένα σύμφωνα με το Evidence Exchange Data Model (EDM). Τα απαιτούμενα πεδία για αναζήτηση (record matching) μπορεί να διαφέρουν ανά είδος εγγράφου και χώρα, οπότε καλό είναι να συμβουλευτείτε το σχετικό μοντέλο δεδομένων στο TDD.
  • Ενδεχομένως επιπλέον μετα-πληροφορίες, όπως γλώσσα προτίμησης ή format, αν υποστηρίζεται από το συγκεκριμένο evidence type.

Για παράδειγμα, ένα QueryRequest XML θα έχει ριζικό element query:QueryRequest που περιλαμβάνει ένα query:Query στοιχείο με τα παραπάνω. Η ακριβής δομή ξεφεύγει από το παρόν έγγραφο, όμως μπορείτε να δείτε παραδείγματα έτοιμων XML (για διάφορα είδη αιτημάτων και απαντήσεων) στο αποθετήριο της Επιτροπής. Τα παραδείγματα αυτά θα σας βοηθήσουν να φτιάξετε σωστά το δικό σας QueryRequest.

Tip: Η Ευρωπαϊκή Επιτροπή παρέχει έναν επίσημο validator για τα XML αιτήματα και τις αντίστοιχες απαντήσεις. Πριν στείλετε το αίτημά σας, συνίσταται να το ελέγξετε μέσω του εργαλείου OOTS Validator. Ανεβάζοντας το XML Request, το εργαλείο θα ελέγξει αν συμμορφώνεται με το σχήμα (XSD) και τις επιχειρησιακές απαιτήσεις του OOTS, βοηθώντας σας να διορθώσετε τυχόν λάθη στη δομή ή στα στοιχεία.

Αφού δημιουργήσετε και επικυρώσετε (validate) το QueryRequest XML, μπορείτε να προχωρήσετε στην αποστολή του μέσω του δικτύου AS4.

Βήμα 3 – Υλοποίηση αποστολής μηνύματος μέσω AS4 (Domibus)

Σε αυτό το βήμα, θα ενσωματώσετε το αίτημα σας (QueryRequest XML) σε ένα AS4 message και θα το στείλετε στον πάροχο μέσω του Domibus (Access Point). Το AS4 μήνυμα βασίζεται σε πρότυπα ebMS3/SOAP: ουσιαστικά, το QueryRequest σας θα αποτελέσει το payload μέσα σε ένα SOAP Envelope μαζί με τα απαραίτητα header.

Βασικά στοιχεία ενός μηνύματος AS4:

• Message ID: Ένα μοναδικό αναγνωριστικό του μηνύματος (URI ή GUID) για κάθε μήνυμα που αποστέλλετε.
• Conversation ID: Ένα αναγνωριστικό συνομιλίας που παραμένει κοινό για όλα τα σχετικά μηνύματα μιας αλληλουχίας (το αρχικό αίτημα και η τελική απάντηση θα μοιράζονται το ίδιο ConversationID). Χρησιμοποιείται για να γίνει συσχέτιση της απάντησης με το αίτημα.
• Party IDs (Αποστολέας/Παραλήπτης): Τα αναγνωριστικά των δύο μερών. Εδώ, ο αποστολέας είναι ο δικός σας οργανισμός (Evidence Requester) και ο παραλήπτης είναι ο φορέας-πάροχος που βρέθηκε από το DSD. Συνήθως πρόκειται για τα Participant Identifiers στο eDelivery. Αυτές οι τιμές θα πρέπει να συμφωνηθούν/διατεθούν από την αρμόδια αρχή (π.χ. μπορεί να είναι URN που περιλαμβάνει ένα κωδικό φορέα και τη χώρα).
• Service και Action: Καθορίζουν το είδος της επικοινωνίας. Στο πλαίσιο του OOTS, θα υπάρχει μια συγκεκριμένη υπηρεσία και δράση που υποδηλώνει “αίτηση αποδεικτικού” (για παράδειγμα, Service=<eb:Service type="urn:oasis:names:tc:ebcore:ebrs:ebms:binding:1.0">QueryManager</eb:Service> και Action=<eb:Action>ExecuteQueryRequest</eb:Action> – ενδεικτικές τιμές, δείτε τα TDD για τις ακριβείς). Αυτές οι τιμές διασφαλίζουν ότι το μήνυμα θα δρομολογηθεί σωστά και θα αναγνωριστεί σωστά από τον αποδέκτη.
• Payload: Το κυρίως περιεχόμενο, που στη δική μας περίπτωση είναι το XML QueryRequest που δημιουργήσατε στο Βήμα 2.

Για να σταλεί ένα μήνυμα μέσω του Domibus, θα πρέπει να τυλιχθεί σε ένα SOAP Envelope με τον κατάλληλο Header (περιέχει τα προαναφερθέντα στοιχεία ebMS3/WS-Security) και το αντίστοιχο Body (που περιέχει το QueryRequest ως payload). Η διαδικασία αυτή μπορεί να υλοποιηθεί είτε χειροκίνητα (δημιουργώντας το SOAP μήνυμα ως string) είτε χρησιμοποιώντας τον Domibus WS Plugin: πρόκειται για μια Web Service διεπαφή που προσφέρει το Domibus, μέσω της οποίας μπορείτε να καλέσετε μεθόδους για την υποβολή μηνυμάτων.

Συνήθως, το Domibus παρέχει ένα αρχείο WSDL για το WS Plugin. Μπορείτε να το εισάγετε στο project σας ώστε να δημιουργηθεί ένας client stub. Έπειτα, καλώντας τη μέθοδο submitMessage (ή άλλη αντίστοιχη, ανάλογα με την έκδοση) θα υποβάλετε το μήνυμα. Για παράδειγμα, σε ένα ελληνικό περιβάλλον OOTS, το WSDL μπορεί να βρίσκεται στη διεύθυνση:

https://ootshub.mindigital.gr/domibus/services/wsplugin?wsdl

(το παραπάνω είναι ενδεικτικό URL – χρησιμοποιήστε το πραγματικό URL του Domibus σας).

Εναλλακτικά, μπορείτε να κατασκευάσετε το SOAP request με κώδικα. Στο documentation του Domibus υπάρχουν παραδείγματα SOAP μηνυμάτων (Envelope) για την αποστολή αιτημάτων και τη λήψη απαντήσεων. Βεβαιωθείτε ότι έχετε ενσωματώσει σωστά τυχόν στοιχεία ασφαλείας (WS-Security headers) εάν απαιτούνται – ωστόσο, σε πολλές περιπτώσεις ο WS Plugin του Domibus χειρίζεται το signing/encryption αυτόματα όταν καλείται μέσω του WSDL client και είστε αυθεντικοποιημένοι.

Υποβολή του αιτήματος: Μόλις το QueryRequest είναι έτοιμο και ελεγμένο, προχωρήστε στην κλήση προς το Domibus. Εφόσον όλα έχουν υλοποιηθεί σωστά, το Domibus θα αποδεχτεί το μήνυμα και θα επιστρέψει αμέσως μια επιβεβαίωσης λήψης (Acknowledgment). Αυτό δεν περιέχει το αποτέλεσμα, απλώς επιβεβαιώνει ότι το Access Point του παραλήπτη έλαβε το μήνυμα. Από εκείνο το σημείο, η διαδικασία γίνεται ασύγχρονη: το σύστημά σας θα πρέπει να περιμένει (ή να ελέγχει περιοδικά) για την μετέπειτα απάντηση από τον πάροχο.

Βήμα 4 – Διαχείριση απάντησης και υλοποίηση μηχανισμού polling

Δεδομένου ότι η απάντηση από την πλευρά του παρόχου μπορεί να καθυστερήσει (συχνά από μερικά δευτερόλεπτα έως αρκετά λεπτά), χρειάζεται να υλοποιήσετε έναν μηχανισμό polling προς το Domibus για να λαμβάνετε την απάντηση μόλις αυτή είναι διαθέσιμη. Το Domibus δεν στέλνει αυτόματα την εισερχόμενη απάντηση προς το backend σας – αντίθετα, τη διατηρεί στην εσωτερική του μνήμη μέχρι να την ανακτήσετε εσείς.

Συνοπτικά, όταν το Domibus λάβει ένα νέο εισερχόμενο μήνυμα (π.χ. την Evidence Response από τον πάροχο), το αποθηκεύει στη βάση του. Θα πρέπει περιοδικά να ερωτάτε το Domibus αν υπάρχουν μηνύματα σε εκκρεμότητα για εσάς (pending messages). Αυτό γίνεται μέσω του WS Plugin, που παρέχει μεθόδους όπως listPendingMessages και retrieveMessage.

Μηχανισμός Polling – Παράδειγμα σε Python

Παρακάτω παρουσιάζεται ένα παράδειγμα υλοποίησης μηχανισμού polling σε Python, το οποίο ελέγχει ανά τακτά διαστήματα για νέες απαντήσεις και ανακτά το μήνυμα όταν φτάσει. Αυτό το παράδειγμα υποθέτει ότι υπάρχει ένας domibus_client (π.χ. ένα αντικείμενο wrapper που κάνει POST κλήσεις στο Domibus WS API) και χρησιμοποιεί απευθείας SOAP requests για απλότητα:

import time, threading, logging

class MessagePoller:
def __init__(self, domibus_client, polling_interval=30):
self.domibus_client = domibus_client
self.polling_interval = polling_interval  # seconds
self.active_conversations = set()        # conversationIds to watch

def start_polling_for_conversation(self, conversation_id):
"""Start polling for responses to a specific evidence request."""
self.active_conversations.add(conversation_id)
# Launch background thread for polling
threading.Thread(target=self._poll_conversation, args=(conversation_id,), daemon=True).start()

def _poll_conversation(self, conversation_id):
"""Poll Domibus for messages related to this conversation."""
timeout_minutes = 60  # Stop polling after 1 hour (for example)
start_time = time.time()
try:
while conversation_id in self.active_conversations:
# Timeout break
if time.time() - start_time > timeout_minutes * 60:
logging.warning(f"Polling for {conversation_id} timed out.")
self.active_conversations.remove(conversation_id)
break
# 1. Έλεγχος για εκκρεμή μηνύματα
pending_messages = self._get_pending_messages()
# 2. Ανάκτηση κάθε μηνύματος και έλεγχος ConversationID
for message_id in pending_messages:
message = self._retrieve_message(message_id)
if message and message.conversation_id == conversation_id:
# Βρέθηκε απάντηση για το ζητούμενο conversation
self._process_evidence_response(message)
self.active_conversations.remove(conversation_id)
return  # exit thread after processing
# Αναμονή πριν τον επόμενο έλεγχο
time.sleep(self.polling_interval)
except Exception as e:
logging.error(f"Error polling for conversation {conversation_id}: {e}")
# Συνεχίζουμε το polling παρά το σφάλμα, με μια καθυστέρηση
time.sleep(self.polling_interval)
self._poll_conversation(conversation_id)

def _get_pending_messages(self):
"""Get list of pending message IDs from Domibus."""
soap_request = """
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsplugin="http://domibus.eu/ws/schema">
<soap:Body>
<wsplugin:listPendingMessagesRequest/>
</soap:Body>
</soap:Envelope>
"""
response_xml = self.domibus_client.post(DOMIBUS_WS_URL, data=soap_request)
return self._parse_pending_messages_response(response_xml)

def _retrieve_message(self, message_id):
"""Retrieve specific message content from Domibus."""
soap_request = f"""
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsplugin="http://domibus.eu/ws/schema">
<soap:Body>
<wsplugin:retrieveMessageRequest>
<wsplugin:messageID>{message_id}</wsplugin:messageID>
</wsplugin:retrieveMessageRequest>
</soap:Body>
</soap:Envelope>
"""
response_xml = self.domibus_client.post(DOMIBUS_WS_URL, data=soap_request)
return self._parse_retrieve_message_response(response_xml)

def _process_evidence_response(self, message):
"""Process the evidence response message (business logic placeholder)."""
# Π.χ. decode base64 payload, save file, update DB, etc.
payload_data = base64.b64decode(message.payload)
save_evidence_file(payload_data, filename="evidence.pdf")
logging.info(f"Evidence response for convo {message.conversation_id} processed.")

Πώς λειτουργεί ο παραπάνω μηχανισμός:

1. Κάθε φορά που στέλνετε ένα νέο Evidence Request, καλείτε π.χ. poller.start_polling_for_conversation(convo_id) με το ConversationID του αιτήματος. Αυτό προσθέτει το convo στη λίστα προς παρακολούθηση και εκκινεί ένα νήμα (thread) που τρέχει τη _poll_conversation.
2. Η _poll_conversation σε βρόχο:

• • Καλεί _get_pending_messages() που στέλνει ένα SOAP αίτημα listPendingMessagesRequest προς το Domibus. Το Domibus ανταποκρίνεται με λίστα από MessageIDs που εκκρεμούν προς ανάκτηση (μηνύματα που έχουν φτάσει αλλά δεν τα έχει πάρει ακόμα κανένας client).
  • Για κάθε message_id που επιστρέφεται, καλεί το _retrieve_message(message_id), που στέλνει αίτημα retrieveMessageRequest στο Domibus για να πάρει το πλήρες μήνυμα. Το Domibus τότε επιστρέφει το περιεχόμενο του μηνύματος (συνήθως ένα SOAP Envelope με το payload σε base64).
  • Ελέγχει το ConversationID του κάθε μηνύματος που έλαβε (το αντικείμενο message υποτίθεται ότι έχει πεδίο conversation_id). Αν ταιριάζει με το ConversationID που παρακολουθούμε, σημαίνει ότι αυτή είναι η απάντηση στο αίτημα μας. Τότε:
    • Καλεί μια μέθοδο _process_evidence_response(message) – εδώ θα βάλετε την επιχειρησιακή σας λογική για να επεξεργαστείτε την απάντηση (π.χ. να αποθηκεύσετε το έγγραφο, να ενημερώσετε τη βάση ότι ολοκληρώθηκε το αίτημα, κ.λπ.).
    • Αφαιρεί το conversation από το ενεργό σετ, και τερματίζει το loop/νήμα.
  • Αν κανένα από τα pending μηνύματα δεν αντιστοιχεί στο conversation μας, το loop κοιμάται (time.sleep) για polling_interval δευτερόλεπτα και ξαναελέγχει.
  • Υπάρχει επίσης πρόβλεψη για timeout: μετά από π.χ. 60 λεπτά, θα σταματήσει να περιμένει άλλο και θα κάνει break, αφαιρώντας το conversation (ώστε να μην τρέχει για πάντα σε περίπτωση που η απάντηση χάθηκε ή καθυστέρησε υπερβολικά).

1. Η _get_pending_messages και _retrieve_message απλώς διαμορφώνουν τα απαραίτητα SOAP envelopes και καλούν τον domibus_client για POST. Η απόκριση χρειάζεται parsing (π.χ. XML parsing) για να εξαχθούν τα IDs και το περιεχόμενο. Αυτές οι βοηθητικές μέθοδοι _parse_pending_messages_response / _parse_retrieve_message_response δεν υλοποιούνται πλήρως στο παράδειγμα, αλλά ουσιαστικά θα πρέπει να διαβάσουν το XML που επιστρέφει το Domibus και να δώσουν τα δεδομένα.
2. Η _process_evidence_response στο παράδειγμα κάνει αποκωδικοποίηση base64 του payload και το αποθηκεύει ως αρχείο PDF. Στην πραγματικότητα, όταν λαμβάνετε ένα μήνυμα από το Domibus WS Plugin, το payload μεταφέρεται ως Base64-encoded string (για να μπορεί να ενσωματωθεί σε XML χωρίς προβλήματα). Θα χρειαστεί λοιπόν να το αποκωδικοποιήσετε. Αν το περιεχόμενο του evidence είναι δομημένο XML (Evidence Response XML) θα το επεξεργαστείτε ανάλογα, ενώ αν είναι αρχείο (π.χ. ένα PDF πιστοποιητικό), η αποκωδικοποίηση θα σας δώσει τα ακατέργαστα bytes του αρχείου, τα οποία μπορείτε να γράψετε σε ένα αρχείο ή να στείλετε στον browser του χρήστη.

Με τον παραπάνω μηχανισμό, η εφαρμογή σας μπορεί να λαμβάνει ασύγχρονα τις απαντήσεις. Εναλλακτικά, αν το πλαίσιο σας το υποστηρίζει, μπορείτε να ενσωματώσετε τον έλεγχο και με άλλους τρόπους (π.χ. cron job ή scheduling service). Το σημαντικό είναι να συνδέετε τις απαντήσεις με τα αιτήματα (μέσω ConversationID) και να διαχειρίζεστε καταστάσεις όπως timeouts ή σφάλματα.

Βήμα 5 - Χειρισμός Σφαλμάτων & Exceptions

Κατά την ανταλλαγή αιτημάτων μέσω του OOTS, μπορεί να προκύψουν σφάλματα από την πλευρά του πάροχου (Evidence Provider). Αυτά τα σφάλματα αποστέλλονται πίσω στον Evidence Requester σε μορφή XML μέσω ενός QueryResponse που περιέχει ένα ή περισσότερα rs:Exception στοιχεία.

Κύριες κατηγορίες Exceptions

• rs:AuthenticationExceptionType – Αποτυχία ταυτοποίησης (EDM:ERR:0001)
• rs:AuthorizationExceptionType – Έλλειψη εξουσιοδότησης / απαίτηση Preview (EDM:ERR:0002)
• rs:InvalidRequestExceptionType – Εσφαλμένο αίτημα (EDM:ERR:0003)
• rs:ObjectNotFoundExceptionType – Δεν βρέθηκε το στοιχείο (EDM:ERR:0004)
• rs:TimeoutExceptionType – Καθυστέρηση απόκρισης (EDM:ERR:0005)
• rs:UnresolvedReferenceExceptionType – Μη αναγνωρισμένη αναφορά (EDM:ERR:0006)
• rs:UnsupportedCapabilityExceptionType – Μη υποστηριζόμενη δυνατότητα (EDM:ERR:0007)
• rs:QueryExceptionType – Γενικό σφάλμα ερωτήματος (EDM:ERR:0008)

Κάθε rs:Exception περιλαμβάνει:

• code – Κωδικός σφάλματος (π.χ. EDM:ERR:0002)
• message – Περιγραφή για τον χρήστη
• detail – Τεχνική περιγραφή
• severity – Βαρύτητα σφάλματος
• Προαιρετικά rim:Slot για επιπλέον πληροφορίες (timestamp, preview link κλπ)

Χειρισμός Authorization ExceptionType με Preview (EDM:ERR:0002)

Πρόκειται για σφάλμα που ΔΕΝ είναι τελικό, αλλά σηματοδοτεί ότι απαιτείται προεπισκόπηση και συναίνεση του χρήστη μέσω Preview Space από την πλευρά του παρόχου.

Τυπικά χαρακτηριστικά:

• xsi:type="rs:AuthorizationExceptionType"
• code="EDM:ERR:0002"
• severity="PreviewRequired"
• rim:Slot name="PreviewLocation" με HTTPS URL
• rim:Slot name="PreviewDescription" με μεταφρασμένα μηνύματα
• rim:Slot name="PreviewMethod" (GET/POST)

Τι πρέπει να γίνει

1. Εμφανίζεται στον χρήστη μήνυμα εξουσιοδότησης με βάση το PreviewDescription
2. Εμφανίζεται κουμπί "Μετάβαση στην Πλατφόρμα Προεπισκόπησης"
3. Μόλις ο χρήστης κάνει κλικ στο κουμπί, το backend δημιουργεί νέο (2ο) QueryRequest με τα ίδια στοιχεία
4. Ο χρήστης ανακατευθύνεται στο PreviewLocation URL για login και επιλογή εγγράφου
5. Μετά την επιβεβαίωση, στέλνεται το 2ο αίτημα μέσω Domibus
6. Ο πάροχος απαντά με το τελικό evidence (PDF ή structured XML)

Παρατηρήσεις

• Το PreviewLocation είναι session-specific URL
• Ο χειρισμός preview είναι man-in-the-loop, απαιτεί δράση χρήστη
• Δεν αποθηκεύεται το preview αποτέλεσμα, η 2η κλήση είναι απαραίτητη

Συνοπτικά tips

• Μην αντιμετωπίζετε EDM:ERR:0002 ως τελικό σφάλμα – είναι αναμενόμενο
• Διατηρείτε το αρχικό ConversationID για συσχέτιση αιτημάτων/απαντήσεων
• Κάντε validate τη 2η απόκριση με τον ίδιο μηχανισμό polling
• Αν η 2η απόκριση αποτύχει, ενημερώνετε τον χρήστη

Επισκόπηση ροής ενεργειών και πρόσθετες πληροφορίες

Ενσωματώνοντας τα παραπάνω βήματα, θα έχετε μια ολοκληρωμένη ροή για την αναζήτηση και λήψη εγγράφων μέσω του OOTS ως Evidence Requester. Συνοψίζοντας την ροή:

1. Ο τελικός χρήστης αυθεντικοποιείται μέσω eIDAS και ξεκινά αίτηση για παροχή δικαιολογητικού (εγγράφου)
2. Το σύστημα του Evidence Requester καλεί το EB για να ανακτήσει Requirements της διαδικασίας
3. Καλεί EB για να λάβει Evidence Types για κάθε Requirement
4. Καλεί το DSD για να εντοπίσει τους παρόχους που διαθέτουν τον ζητούμενο τύπο εγγράφου
5. Δημιουργεί το XML QueryRequest
6. Στέλνει το XML QueryRequest στον πάροχο μέσω Domibus/AS4
7. Ο πάροχος επιστρέφει:

• • είτε απευθείας απάντηση με το έγγραφο
  • είτε QueryResponse με Exception τύπου AuthorizationExceptionType (PreviewRequired)

1. Αν είναι PreviewRequired:

• • Η εφαρμογή εμφανίζει κουμπί "Μετάβαση σε Preview Space"
  • Ο χρήστης ανακατευθύνεται στο preview link (PreviewLocation) του παρόχου
  • Ο χρήστης επιλέγει/εγκρίνει τα στοιχεία στο preview page

1. (Παράλληλα με το βήμα 8) Το backend στέλνει δεύτερο QueryRequest στον ίδιο πάροχο
2. Ο πάροχος απαντά με το έγγραφο (PDF ή structured XML)
3. Το backend παραλαμβάνει, αποκωδικοποιεί και επεξεργάζεται την απάντηση
4. Το έγγραφο αποθηκεύεται και διατίθεται στον τελικό χρήστη

Τέλος, αξίζει να αναφερθεί ότι όλα τα τεχνικά χαρακτηριστικά του OOTS, συμπεριλαμβανομένων των data models, API specs και σεναρίων, περιγράφονται αναλυτικά στα Technical Design Documents (TDD) της Ευρωπαϊκής Επιτροπής. Για πλήρη συμμόρφωση, θα πρέπει να συμβουλεύεστε τα έγγραφα αυτά κατά την ανάπτυξη.

Υλοποίηση Proof of Concept

Τελευταία ενημέρωση 17-07-2025

Στο παρακάτω link μπορείτε να αποκτήσετε πρόσβαση σε μια Proof-of-Concept εφαρμογή που αναπτύχθηκε και ενσωματώνει τη ροή που περιγράψαμε παραπάνω. Χρησιμοποιείται το Πιστοποιητικό Γέννησης ως requirement και η Κύπρος ως χώρα παροχής του εγγράφου.

Link εφαρμογής: https://wiki-ootshub.mindigital.gr/app3

Για παράκαμψη του eIDAS login, κάνετε κλικ στο κουμπί Bypass login και μπορείτε να χρησιμοποιήσετε τα στοιχεία ενός test user από την Κύπρο:

• First Name: CHRISTAKIS
• Last Name: ILIA
• User ID: 0000734450
• Email: 0000734450@eidas.gr
• Birth Date: 20/11/1971

Αφού δημιουργήσετε μια νέα αίτηση πιστοποιητικού, στο τελευταίο βήμα στην ενότητα Documents attachement επιλέγετε το PROOF OF BIRTH και κάνετε κλικ στο Retrieve online. Στην συνέχεια ανοίγει ένα pop-up παράθυρο στο οποίο επιλέγετε:

• Country: Cyprus
• Evidence Type: Proof of Birth (PDF/XML)
• Provider: Civil Registry and Migration Department

Αφού προχωρήσετε και ολοκληρωθεί η κλήση θα σας εμφανιστεί ένα κουμπί Preview & Retrieve, το οποίο επιλέγετε και ανακατευθύνεστε στο Preview Space της Κύπρου. Εκεί θα σας ζητηθεί να εισάγετε τα credentials του test user:

• Username: sdguser1
• Password: !Qwerty1!

Στη συνέχεια, επιλέγετε το ζητούμενο αρχείο, μπορείτε να κάνετε Preview και, τέλος, κάνετε κλικ στο Send.

Τέλος, αφού επιστρέψετε στην αρχική εφαρμογή, σας εμφανίζεται πάλι το ίδιο pop-up και ένα κουμπί Download Evidence File, στο οποίο πρέπει να κάνετε κλικ για να δείτε το ζητούμενο πιστοποιητικό-έγγραφο και ολοκληρώνετε την απαιτούμενη ροή.