Standards:IG Secure EnrollRequest
- 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:38 CEST 2012" repository="Secure" last="" source="EnrReq_Intro.txt" conversion="none">
Introduction
This document describes the contents of the Sepamail message used to register one or several new certificates.
The full name of this message, which is part of the secure ecosystem, is sepamail_message_secure_EnrollRequest.
This message must be generated and sent by the person or organization wishing to enroll, ie become part of the Sepamail community. This includes mostly three cases :
- addition of a new bank to the Sepamail "bank pool"
- subscription to the system, by a new individual or corporate entity
- removal from the system of a user, or of a certificate
Once this message has been received and accepted, by means of an EnrollReport message, the new person or organization's credentials are known to the Sepamail system and accepted by it, so that it can now send any kind of messages, belonging to the declared message families, to the Sepamail system through any exchange mechanism.
If the message is used to remove a certificate or a user, if must also be replied with an EnrollReport message, acknowledging the removal of the required certificates.
It must be remembered that, in the Sepamail system, two certificates are used for each message : one for signing, and one for ciphering. In this message, certificates are always handled as pairs, to facilitate things.
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. Please note that this non-ISO part is based on the XMLSignature standard. </svnig>
<svnig revision="" date="Tue Aug 07 11:27:38 CEST 2012" repository="Secure" last="" source="EnrReq_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:38 CEST 2012" repository="Secure" last="" source="EnrReq_Abstract.tab" conversion="tab">
| Mult | Message Element | Sepamail requirement |
|---|---|---|
| [1..1] | sepamail_message_secure_enroll_request_001 | First version of this message |
</svnig>
<svnig revision="" date="Tue Aug 07 11:27:38 CEST 2012" repository="Secure" last="" source="EnrReq_Body.txt" conversion="none">
EnrollRequest body
This part of the message actually describes the identification of the party wishing to enroll, and the associated certificates. </svnig>
<svnig revision="" date="Tue Aug 07 11:27:38 CEST 2012" repository="Secure" last="" source="EnrReq_Body.tab" conversion="tab">
| Ref | Mult | Message Element | Sepamail requirement |
|---|---|---|---|
| A1 | [1..1] | ++ CreDtTm | Creation date and time, ISO format |
| A2 | [0..1] | ++ SndrRef | Sender Reference. Internal reference the sender associates with this request |
| A3 | [1..1] | ++ EnrollCode | Code generated by requestor, and used later to check his/her identity. |
| A4 | [1..1] | ++ Sndr | Sender description |
| A4.1 | [0..1] | +++ Nm | Mandatory |
| A4.2 | [0..1] | +++ PstlAdr | |
| A4.3 | [0..1] | +++ Id | |
| A4.3.1 | {Or | ++++ OrgId | |
| A4.3.2 | Or} | ++++ PrvtId | |
| A4.4 | [0..1] | +++ CtryOfRes | |
| A4.5 | [0..1] | +++ CtctDtls | |
| A4.6 | [0..1] | +++ CdtrAcct | |
| A5 | [1..1] | ++ SndrBIC | Mandatory, standard BIC format |
| A6 | [1..1] | ++ SndrQxCard | Mandatory |
| A6.1 | [1..1] | +++ PartyName | Mandatory, text-only identifier of party. This should be the legal identifier (registered name, for instance) |
| A6.9 | [0..1] | +++ DisplayName | Party name, as will be displayed |
| A6.2 | [1..1] | +++ RIS2D | Mandatory |
| A6.3 | [0..1] | +++ Test | should be set to "true" if this is a testing-only party |
| A6.4 | [1..1] | +++ QXBAN | Mandatory, can be an IBAN if the QXBAN is not available. |
| A6.5 | [0..1] | +++ ICQX | |
| A6.6 | [0..n] | +++ Services | Describes Sepamail services supported by party. Possible values are "GEMME", "RUBIS" ... |
| A6.7 | {Or | +++ DbtrElements | Debtor-specific elements, currently none. |
| A6.8 | Or} | +++ CdtrElements | Creditor-specific elements |
| A6.8.1 | [0..1] | ++++ Logo | |
| A6.8.2 | [0..1] | ++++ Thumbnail | |
| A6.8.3 | [0..n] | ++++ customerHelp | Elements describing where the customer references may be found by the debtors |
| A6.8.3.1 | [1..1] | +++++ identifierName | Used to differentiate between identifiers |
| A6.8.3.2 | [1..n] | +++++ helpText | Textual parts |
| A6.8.3.3 | [0..n] | +++++ helpImage | Illustrations, if necessary |
| A7 | [1..n] | ++ CommunicationElement | Mandatory. One such element must be present for each certificate the sender wishes to register. (Reminder : Sepamail messages are grouped into ecosystems, and each ecosystem can use a different certificate.) |
| A7.1 | [1..1] | +++ CertifId | Mandatory. This identifier can contain anything ; it will be used in the EnrollReport message to identify this particular certificate. |
| A7.2 | [1..1] | +++ Allow | Mandatory. This boolean indicates whether the certificates must be added to the Sepamail system (true), or removed from the system (false). Although it is possible, in the same message, to remove some certificates and add some other ones, this practice is discouraged. |
| A7.3 | [1..1] | +++ SignKey | Mandatory. Contains the certificate for which enrollment is requested. This is the signing certificate. |
| A7.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. |
| A7.3.2 | [0..1] | ++++ KeyValue | |
| A7.3.3 | [0..1] | ++++ RetrievalMethod | |
| A7.3.4 | [0..1] | ++++ X509Data | Mandatory, with all available sub-elements filled in. |
| A7.3.5 | [0..1] | ++++ PGPData | |
| A7.3.6 | [0..1] | ++++ SPKIData | |
| A7.3.7 | [0..1] | ++++ MgmtData | |
| A7.3.8 | [0..1] | ++++ Other | |
| A7.4 | [0..1] | +++ CryptKey | Contains the certificate, if any, for which enrollment is requested. This is the ciphering certificate. If the third party only communicates through HTTPS exchange mechanisms, this certifcate may be absent. |
| A7.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. |
| A7.4.2 | [0..1] | ++++ KeyValue | |
| A7.4.3 | [0..1] | ++++ RetrievalMethod | |
| A7.4.4 | [0..1] | ++++ X509Data | Mandatory, with all available sub-elements filled in. |
| A7.4.5 | [0..1] | ++++ PGPData | |
| A7.4.6 | [0..1] | ++++ SPKIData | |
| A7.4.7 | [0..1] | ++++ MgmtData | |
| A7.4.8 | [0..1] | ++++ Other | |
| A7.5 | [1..n] | +++ Family | Mandatory. Designates the message ecosystem(s) for which the certificate will be used. Possible values are "test", "secure", "scheme", "direct.debit" and "payment.activation". It must be noted that the same ecosystem may be present more than once, among all CommunicationElement elements. This allows for instance the use of two certificates for the same ecosystem : one with a password, and one without password. |
</svnig>