Standards:IG Secure EnrollReport
- These implementation rules shall be applied in accordance with ISO20022 and SEPA own implementation rules. Thus, unless explicitly specified, data contained within a field or XML structure of a SEPAmail message must comply with the constraints related to the equivalent field or XML structure in ISO20022 or SEPA messages.
- for an explanation of the color coding used in the tables below, see this page
- for general rules applying to all fields, see this page
- for business rules directing these IG, see this page
<svnig revision="" date="Tue Aug 07 11:27:33 CEST 2012" repository="Secure" last="" source="EnrRep_Intro.txt" conversion="none">
Introduction
This document describes the contents of the Sepamail message used to accept or reject a new certificate.
The full name of this message, which belongs to the SAPPHIRE service family, is sepamail_message_secure_EnrollReport.
This message must be generated and sent by the organization receiving an EnrollRequest message, whether this message has been sent by a bank joining the Sepamail system, or by an individual or corporation wishing to use its services.
The EnrollReport message has two aims :
- accepting or rejecting each pair of certificates submitted by the sender
- transmitting the receiver's own certificate(s) for the related message ecosystems
It can also be used to transmit additional data to the sender, such as a Sepamail Identifier (RIS).
This message is not based upon any existing ISO schema, since no such message exists in their model. Thus, it only includes a non-ISO part, described here. </svnig>
<svnig revision="" date="Tue Aug 07 11:27:33 CEST 2012" repository="Secure" last="" source="EnrRep_Abstract.txt" conversion="none">
Internal abstraction level
To facilitate upgrades, an abstraction level has been inserted at the root of this element. </svnig>
<svnig revision="" date="Tue Aug 07 11:27:33 CEST 2012" repository="Secure" last="" source="EnrRep_Abstract.tab" conversion="tab">
| Mult | Message Element | Sepamail requirement |
|---|---|---|
| [1..1] | sepamail_message_secure_enroll_report_001 | First version of this message |
</svnig>
<svnig revision="" date="Tue Aug 07 11:27:33 CEST 2012" repository="Secure" last="" source="EnrRep_Body.txt" conversion="none">
EnrollReport body
This part of the message indicates the result of the enrollment, and if positive, carries additional information for the new member. </svnig>
<svnig revision="" date="Tue Aug 07 11:27:33 CEST 2012" repository="Secure" last="" source="EnrRep_Body.tab" conversion="tab">
| Ref | Mult | Message Element | Sepamail requirement |
|---|---|---|---|
| A1 | [1..1] | ++ CreDtTm | Creation date and time, ISO format |
| A2 | [1..1] | ++ SndrRef | Sender Reference. This reference must be the one used in the same element of the EnrollRequest message. |
| A3 | [1..n] | ++ Report | Mandatory. One such element must be present for each CommunicationElement in the EnrollRequest message. |
| A3.1 | [1..1] | +++ CertifId | Mandatory. Must match the referred CommunicationElement. |
| A3.2 | [1..1] | +++ Accepted | Mandatory. true means the certificates are accepted as valid, and will be used from now on for the related message ecosystem(s). false means the certificates are rejected, and cannot be used. Other certificates will have to be submitted by the sender. The false value must also be used when replying to a removal request, to confirm deactivation of the certificates. |
| A3.3 | [0..1] | +++ Reason | Optional, but strongly recommended if the certificate is rejected : human-readable explanation of rejection. |
| A4 | [0..1] | ++ OtherIdentif | May be used to return a Sepamail Identifier to the sender |
| A5 | [0..n] | ++ CommunicationElement | Mandatory, except when replying to a removal request. One such element must be present for each certificate the replier wishes to communicate to the sender. Normally, certificates should be sent for each message ecosystem requested by the sender and supported by the receiver. |
| A5.1 | [1..1] | +++ CertifId | Mandatory. This identifier must be present but is not used in the current flow of messages. |
| A5.2 | [1..1] | +++ Allow | Mandatory, and must be set to true in this case. |
| A5.3 | [1..1] | +++ SignKey | Mandatory. Contains the signing certificate. |
| A5.3.1 | [0..1] | ++++ KeyName | Mandatory. Indicates the element upon which the certificate is based. For inter-bank enrollment, this should be a mail address. For other cases, other identifiers are possible. |
| A5.3.2 | [0..1] | ++++ KeyValue | |
| A5.3.3 | [0..1] | ++++ RetrievalMethod | |
| A5.3.4 | [0..1] | ++++ X509Data | Mandatory, with all available sub-elements filled in. |
| A5.3.5 | [0..1] | ++++ PGPData | |
| A5.3.6 | [0..1] | ++++ SPKIData | |
| A5.3.7 | [0..1] | ++++ MgmtData | |
| A5.3.8 | [0..1] | ++++ Other | |
| A5.4 | [1..1] | +++ CryptKey | Mandatory. Contains the ciphering certificate. |
| A5.4.1 | [0..1] | ++++ KeyName | Mandatory. Indicates the element upon which the certificate is based. For inter-bank enrollment, this should be a mail address. For other cases, other identifiers are possible. |
| A5.4.2 | [0..1] | ++++ KeyValue | |
| A5.4.3 | [0..1] | ++++ RetrievalMethod | |
| A5.4.4 | [0..1] | ++++ X509Data | Mandatory, with all available sub-elements filled in. |
| A5.4.5 | [0..1] | ++++ PGPData | |
| A5.4.6 | [0..1] | ++++ SPKIData | |
| A5.4.7 | [0..1] | ++++ MgmtData | |
| A5.4.8 | [0..1] | ++++ Other | |
| A5.5 | [1..n] | +++ Family | Mandatory. Designates the message ecosystem(s) for which the certificate will be used. Possible values are test, secure, direct.debit and payment.activation |
</svnig>