...

{"event_type": "CERTIFICATE_REVOKED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "ISSUED"}, "certificates": [{"status": "REVOKED", "serial_number": "XXXXXXXXXXXXXXX", "valid_from": "YYYYMMDD HH:MM:SS", "valid_to": "YYYYMMDD HH:MM:SS"}]}

2.2. Flow states of a VideoID Request

1. Request Created

{"event_type": "REQUEST_CREATED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "VIDEOPENDING", ...}, "certificates": []}

a. Request canceled

{"event_type": "REQUEST_CANCELED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "CANCELLED", ...}, "certificates": []}

2. VideoID completed by the User

2.1. The data has been approved by the service and is being processed

{"event_type": "VIDEOID_UPDATED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "VIDEOINCOMPLETE", ...}, "certificates": []}

2.2.Request rejected due to a documentation-related issue

{"event_type": "VIDEOID_FAILED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "VIDEOERROR", ...}, "certificates": []}

3. Data ready for review

{"event_type": "VIDEOID_UPDATED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "VIDEOREVIEW", ...}, "certificates": []}

4. Approval or rejection by RAO

4.1. Approval

{"event_type": "REQUEST_APPROVED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "ENROLLREADY", ...}, "certificates": []}

4.2. Rejection

{"event_type": "VIDEOID_REFUSED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "CANCELLED", ...}, "certificates": []

5. Request in issued state (Certificate issued)

{"event_type": "REQUEST_ENROLLED", "sent_at": "YYYYMMDDHHMMSS", "request": {"status": "ISSUED"}, "certificates": [{"status": "VALID", "serial_number": "XXXXXXXXXXXXXXX", "valid_from": "YYYYMMDD HH:MM:SS", "valid_to": "YYYYMMDD HH:MM:SS"}]}

3.Event Structure

Here the key focus is on the “status” attribute, as it is a present in both the request object and the certificates object. It is essential to understand that these “status” attributes are not comparable to each other, as they represent different entities:

The request.status key is the primary one within this context because it represents the state of the issuance process. This “status” is directly related to the request’s flow and reflects its progress or completion.

request.status: indicates the status of the request.

certificates[].status: indicates the status of the certificate.

Althought both share the same key name, each belongs to a different context and carries a specific meaning.