Copyright notice

ISO/TC 154 N381
DRAFT ISO/CD 22208-1
Processes, data elements and documents in commerce, industry
and administration — Rules for the operation of EDI/EC registration
authorities — Part 1: Scheme code registration system
THIS DOCUMENT IS A DRAFT. IT IS THEREFORE SUBJECT TO CHANGE AND MAY NOT BE
REFERRED TO AS AN ISO PUBLICATION UNTIL PUBLISHED AS SUCH
Copyright notice
This ISO committee draft is copyright-protected by ISO. Except as permitted under theCopyright Laws of the user's country, no extract of this ISO draft may be reproduced, stored in aretrieval system or transmitted in any form or by any means, electronic, photocopying, recordingor otherwise, without prior written permission being secured.
Requests for permission to reproduce should be addressed to: Mr. Jean KublerISO/TC154 SecretaryUN/ECE Trade DivisionPalais des NationsCH – 1210 GenevaE-Mail: Contents
1 Scope.…………………………………………………………………………………….
2 Normative references.…………………………………………………………………………………….
3 Definitions.………………………………………………………………………………………
4 Conventions.…………………………………………………………………………………….….
5 Identification Structure.……………………………………………………………………
6 Conditions relating to the schemes ……………………………………………………………………….
7 Scheme characteristics and provisional scheme types ………………………………………………
8 Sub-authorities ……………………………………………………………………………………………….
9 Directory Services ……………………………………………………………………………………………
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standardsbodies (ISO member bodies). The work of preparing International Standards is normally carried outthrough ISO technical committees. Each member body interested in a subject for which a technicalcommittee has been established has the right to be represented on that committee. Internationalorganizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISOcollaborates closely with the International Electrotechnical Commission (IEC) on all matters ofElectrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part3.
Draft International Standards adopted by the technical committees are circulated to the memberbodies for voting. Publication as an International Standard requires approval by at least 75 % of themember bodies casting a vote.
ISO 22208 consists of the following parts, under the general title Rules for the operation of /ElectronicCommerce Registration Authorities (ECRA).
— Part 1: Scheme code registration system — Part 2: Application and registration procedures Annexes A forms a normative part of this part of ISO 22208-1. Annexes B and C are informative.
Introduction
The use of electronic communications media and services internationally for the transmission ofinformation between organizations is continuing to increase dramatically.
In developing this standard, it was recognised that a single universal registration scheme foridentifying organizations at international level is not practical and will allow the co-existence of severalregistration schemes identified in the framework of a global registration infrastructure. It will help aparty wishing to register, to make an objective decision as to the registration scheme which it shouldselect and for the recipient of a data interchange to assess what reliance may be placed in theidentifier of an E-Commerce partner.
This global registration infrastructure will encourage the provision of Directory services and assist inthe development of security services associated with the registration process.
This international standard:1. is focused on registration worldwide;2. is able to encompass registration schemes already in use and also future schemes developed in the framework of this proposed International standard; 3. defines provisional and non restrictive set of types of schemes having different characteristics.
The scheme types differ in terms of level of resources put into managing the allocation and use ofECRA-identifiers; 4. refers to and is compliant with International standards covering registration with UN/EDIFACT and Each ECRA registration scheme will be identified by the allocation of a unique registration schemeidentifier. The allocation of such identifiers for coding schemes which identify organizations is currentlyregulated by ISO 6523.
Calculation and validation of the check digits are defined in Annex A (normative)
Examples of coding to be used for the <EDI origin/destination> structure in an EDIFACT environment
as defined by [EDIFACT] and [EDIFACT Amd.1] and in an ANSC X12 environment as specified in
[X12] (informative)
Application of Business Identifiers in X.509 Public Key Certificates is provided in Annex C (informative)
Processes, data elements and documents in commerce, industry
and administration — Rules for the operation of EC registration
authorities - Part 1: Scheme code registration system
This International Standard provides a basis for global unambiguous identification of organizationsinvolved in Electronic Commerce and also provides adequate mechanisms for the operation of areliable registration scheme.
This International Standard allows the co-existence of several registration schemes identified in theframework of a global registration infrastructure. By publishing the terms of service of these ECRAregistration schemes, this International Standard will help a party wishing to register, to make anobjective decision as to the registration scheme which it should select and for the recipient of a datainterchange to assess what reliance may be placed on the EC identifier.
This global registration infrastructure will encourage the provision of Directory services and assist inthe development of security services associated with the registration process.
2 Normative references
The following standards contain provisions which, through reference in this text, constitute provisionsof this International Standard. At the time of publication, the editions indicated were valid. All standardsare subject to revision, and parties to agreements based on this International Standard areencouraged to investigate the possibility of applying the most recent editions of the standardsindicated below.
Members of IEC and ISO maintain registers of currently valid International Standards.
ISO 3166:1997, Codes for the representation of names of countries. ISO 6523:1998, Data Interchange-Structure for the Identification of Organizations Part 1: Identification of organization identification schemes Part 2: Registration of organization identification schemes. ISO 7372:1993, Trade data interchange - Trade data elements directory ISO/IEC 8824:1990, Information technology - Open Systems Interconnection - Abstract Syntax No.1 ISO 8859-1:1987, Information processing -8-bit single byte coded graphic character sets.
Note: the following character sets are now covered: ISO 9735: Electronic data interchange for administration, commerce and transport(EDIFACT)- Application level syntax rules version 3 and 4. ISO/IEC 9834-1:1992, Procedures for the operation of OSI Registration Authorities ISO/IEC10594, Information Processing Systems- Open Systems Interconnection – The Directory. 3 Definitions
3.1 Electronic Commerce (EC): electronic communication between partners in the form of a
structured set of information. Electronic commerce relationships include all kind of information
interchanges as B to B EDI exchanges (UN/EDIFACT, ANSI X. 12, XML EDI), security related
interchanges (such as pkcs, pkix, standard objects such as X509 certificates, B to C, or individuals to
public bodies.
3.2 EC identifier: a registered identification of an organisation, used to identify EC partners. It shall be
possible to derive the identity of the Legal Person from this identifier only.
This identifier is assigned within a registration scheme and is unique within that scheme.
3.3 EC sender/recipient: the identification of the organisation taking responsibility as the
sending/receiving partner for a data interchange. The identification consists of an EC identifier,
together with an optional associated organisation - free part.
3.4 Edira Business Identifier Code (EBIC): The data element used to uniquely identify a registration
scheme.
3.5 EBIC value: The identifier allocated to a particular EBIC; it has a variable length up to 4 digits.
3.6 Electronic Commerce Registration Authorities (ECRA): an infrastructure for the allocation and
management of EC identifiers, through a set of registration authorities, each of which has been
allocated an EC identifier.
3.7 International Code Designator (ICD): The ISO-specified data element used to uniquely identify a
registration scheme. (ISO/IEC 6523-1).
It can be used as an EBIC.
Note 2: the ICD value has a variable length of up to 4 digits.
3.8 organization: A unique framework of authority within which a person or persons act, or are
assigned to act, toward some purpose. (ISO/IEC 6523-1)
Note 1: The kinds of organizations covered by this part of ISO 22 208 include the following examples:
a) an organization incorporated under law
b) an unincorporated organization or activity providing goods and/or services including:
1) partnerships;2) social or other non-profit organizations or similar bodies in which ownership or control is vested in a group of individuals; c) groupings of the above types of organizations where there is a need to identify these ininformation interchange.
3.9 Organization Identifier (OI): The identifier assigned to an organization within a registration
scheme, and unique within that scheme.
3.10 organization part: Any department, service or other entity within an organization, which needs to
be identified for information interchange (ISO/IEC 6523-1).
3.11 organization part identifier (OPI): An identifier allocated to a particular organization part.
(ISO/IEC 6523-1)
3.12 OPI source indicator (OPIS): The data element used to specify the source for the organization
part identifier.(ISO/IEC 6523-1)
3.13 OPIS value: The particular value taken by the OPIS to designate the source of an organization
part identifier.(ISO/IEC 6523-1)
3.14 registration: the assignment of an EC identifier in a way which makes the assignment available
to interested parties. It is carried out by a Registration authority (derived from ISO/IEC 9834: 1992).
3.15 registration scheme: The set-up of the scheme of a particular Registration authority expressed
in terms of a minimum set of key characteristics.
3.16 registration authority: the operator of one and only one registration scheme.
3.18 sub-authority: an operator contracted by a registration authority to supply a registration service
within the scope of the relevant registration scheme.
4 Conventions
This International Standard uses the following conventions for data element representations based onISO XXXXX.
n : digits (numeric characters 0 to 9 only) a : letters (alphabetical characters A through Z only) an : letters and digits (alpha/numeric without “special” characters such as blanks, separators,punctuation etc.) x : any character of the permitted character set as specified in the given application 5 Identification structure
Each ECRA registration scheme will be identified by the allocation of a unique registration schemeidentifier. The allocation of such identifiers for coding schemes which identify organizations is currentlyregulated by ISO 6523.
The structure is illustrated in the following figure: The format of these data elements is the following:- EBIC (ICD) integer, variable length, up to 4 digits included in the EBIC value- OI - Identification of an organization variable length, up to 35 characters- OPI the OPI is allocated by the registration authority the OPI is allocated by the registered organization the OPI is allocated according to agreements between theinterchange partners 6 Conditions relating to the schemes
This International Standard covers international schemes (e.g. Dun & Bradstreet, EAN Internationaland the Bank Identifier Code scheme under ISO 9362) and national schemes (e.g. SIREN/SIRETnumbers issued by INSEE in France). The schemes shall identify, as far as possible, the majority ofbusiness entities. The schemes shall be in the public domain and where practicable, be accessible torequests for information.
Where one scheme alone does not cover all business entities or, where national situations require, alimited number of schemes may be registered to identify business entities.
Where no one such scheme is available within a country, an alternative internationally availablescheme, or ISO Standard scheme which meets the requirements of this International Standardmay be designated.
7 Scheme characteristics and provisional scheme types
Key characteristics
Each registration authority is required to provide a description of its scheme.
8 Sub-authorities
A registration authority may contract with one or more sub-authorities to operate the registrationfunctions, for which that signatory has been approved. The registration authority takes completeresponsibility for any such sub-authorities to honour all relevant elements in respect of thisInternational standard.
A sub-authority is defined as operating within the technical and contractual agreements of theregistration authority to which it is contracted. The identification domain of a sub-authority shall be asubset of the identification domain of the registration authority to which it belongs. The scheme(s)supported by the sub-authority shall not be outside the schemes operated by its parent registrationauthority.
The registration authority may publish the rules for the selection and operation of sub-authorities whichoperate within the same registration scheme, together with a list of current sub-authorities approved.
The identification of a sub-authority, if required, is completely under control of the registration authorityand may be coded in the registered organization identifier.
9 Directory Services
A registration authority may provide a Directory service. The registration authority may subcontractunder appropriate contractual conditions to provide registration data to any Directory serviceprovider(s) willing to operate a service based on the ECRA identification.
Calculation and validation of the check digits
A.1 Calculation of the check digits
a) Delete all non-alphanumeric characters and spaces.
b) Convert letters to digits in accordance with table 1:c) Apply the check character system MOD 97-10 (see ISO 7064).
Table 1 — Validation of Check Digits
Validation of Check Digits
Conversion of letters to digits
A.2 Validating the check digits on the EC identifier
The following is a method of validating the check digits of the EC identifier.
a) take the EC identifier (which includes the check digits);b) divide by 97;c) subtract the resultant whole number from the original whole number. If the remainder is 1 the (informative)
This annex specifies the coding to be used for the EDI origin/destination structure in an EDIFACT
environment as defined by [EDIFACT] and [EDIFACT Amd.1] and in an ANSC X12 environment as
specified in [X12].
Definitions
This section defines the terms EDI sender/recipient structure and EDI sender/recipient coding.
Figure 1 illustrates the concepts that are developed.
EDI origin/destination structure
EDI sender/recipient structure is an abstract concept. A registration authority allocates an EC-
identifier according to a defined registration scheme. The EC identifier is then used in an [EDIFACT]
message as the first part of the EDI sender/recipient.
B.1.2 EDI sender/recipient coding
An EDI sender/recipient may be coded within a computer system. This, for example, may be for thepurpose of transmission on a data communications link, for internal data processing or for storage onsome physical storage device such as a disk. The coding of a single EDI sender/recipient may bedifferent for each one of the applications in the example. In each case, irrespective of the coding, thesemantics associated with the EDI sender/recipient remains the same.
When it is used within the body of an EDI transfer, the coding of the EDI sender/recipient depends onthe EDI syntax in use (e.g. EDIFACT and X12) and the "standard" that defines the coding.
Neither the EDIFACT standard nor the ANSC X12 standard define the EDI sender/recipient structurethat is used respectively in the data elements UNB/S002 and UNB/S003 or ISA06 and ISA08. Thesestandards only provide general coding rules.
From now onwards in this annex, for convenience, reference is made only to UNB/S002 in the case ofEDIFACT and to ISA06 in the case of X12.
Figure 1 below illustrates these concepts.
Figure 1 - Structure and Coding
B.2 The EDI sender/recipient structure
The EDI sender/recipient structure takes into account existing registration schemes (e.g. EAN, DUNS,
SWIFT, [OSI Reg Auth].
The EDI sender/recipient structure is described in two abstract levels. This separates considerations
of character repertoire from those of the internal structure.
EDIFACT case
At the highest level, the EDI sender/recipient structure consists of an alphanumeric string taken from
the character repertoire specified in data element UNB/S001/0001.
It is recommended that in the long term, for UE countries, apart from Greece, the value used in data
element UNB/S001/0001 is UNOC (the repertoirdefined in ISO Registration Numbers 6 and 100
which is identical to the repertoire defined in [Latin-1]).
Latin-1 caters for a high proportion of languages using the Latin script in the EU. Note that [EDIFACT
Amd.1] does allow the use of this repertoire.
In the short to medium term, it is recommended that the repertoire actually used be restricted to the
[EDIFACT] Level A repertoire (UNOA) which is a sub repertoire of that defined in IR 6. This is in
recognition of current practice. It is believed that, as the use of EDI expands in Europe, users will
increasingly demand that messages (and identifiers) should be capable of being expressed in national
character repertoires.
The basic underlying assumption of this annex is that the length of the EDI sender/recipient when
coded should fit in data elements UNB/S002/0004 and 0007 of the [EDIFACT] syntax. There may be
other restrictions that have to be applied if the EDI sender/recipient is coded in other syntaxes.
ANSC X12 case
At the highest level, the EDI sender/recipient structure consists of an alphanumeric string taken from
the character repertoire specified in ANSC X12.6. In its clause 3.3, this standard specifies that all
element values, except those of binary data elements, shall be constructed using one of two character
sets, the basic character set or the extended character set. As this latter set may only be used by
agreement between the communicating parties, it is not adequate for application within an open
environment.
The basic character set will therefore be used, with the exception of the special characters because of
their potential use as delimiters. Therefore the recommended character set is composed of :
uppercase letters from A to Z,
digits from 0 to 9,
the space character.
The basic underlying assumption of this annex is that the length of the EDI sender/recipient when
coded should fit in data elements ISA05 and ISA 06 of the [X12] syntax. This assumption introduces
significant restrictions in comparison with the possibilities offered by the corresponding fields in the
EDIFACT syntax.
For the purposes of this section, the description of the coding is restricted to the EDIFACT
environment according to [EDIFACT] and [EDIFACT Amd.1] and to the ANSC X12 environment
according to [X12].
B.3.1 Coding in EDIFACT
Character Repertoire Coding
1 The distinction is made between character repertoire and coded character set. ECMA operates theISO 2375 International Register. The registration of a coded character set defines the characterrepertoire, its coding and the associated ESCAPE sequences.
The characters used shall be coded according to the code table specifications found in theInternational Register entries for the selected repertoire.
registration scheme identifier
ISO 6523 should be used to identify a registration scheme.
registered organization identifier
The registered organization identifier is coded in data element UNB/S002/0004.
One or more check characters may be added to the end of the registered organization identifier. Thealgorithm for deriving the check character is registration scheme dependent.
organization - free part
The organization - free part is coded as a continuation of the registered organization identifier in dataelement UNB/S002/0004.
One or more check characters may be added to the end of the registered organization identifier. Thealgorithm for deriving the check character is registration scheme dependent and may use both theregistered organization identifier and the organization - free part as input.
Coding in X12 NO COMMENT since I don’t know X.12 at all
Character Repertoire Coding
The characters used shall be coded according to the code table specifications found in theInternational standards pertaining to ASCII.
registration scheme identifier
Currently two authorities allocate scheme identifiers for registration schemes. Both ISO 6523 through
the ICD and ANSC through the code set I05 (Interchange ID qualifier, IIQ) identify registration
schemes through the allocation of code values.
It is proposed that ISO 6523 should be used as the method of identifying a registration scheme.
It is proposed that ANSI should be requested to acknowledge the relevance of ISO 6523 and move
towards the exclusive use of the ISO 6523 ICD value for the code set I05.
However, while the ICD values are coded using four digits, from 0001 to 9999, the Interchange ID
qualifier may only be coded as two alphanumerical characters. This severely restricts the allowable
coding space to 362 - 1 (1295), as the value 00 does not seem to be used.
For X12 to use the ISO 6523 ICD values, a mapping scheme is therefore required.
it is also required to maintain and publish to all X12 users a table of correspondence between a subset
of the ICD values allocated under the ISO 6523 scheme and the values in ISA05.
A better approach would imply using a transformation algorithm providing an easy mechanical
mapping between the two code lists. An example of such an algorithm is a number conversion
between the two bases 10 for the ICD values and 36 for the ISA05 values (36 being the total number
of signs available from the 10 digits and the 26 letters excluding space).
If a mechanism is put in place such that registration schemes receive the same interchange ID
qualifier as results from such a transformation from the allocated ICD value, then migration towards a
synonymous set of values can be put under way.
Procedures will also be required for an unbounded interim period to deal with instances where the two
values do not align or create ambiguities. A published mapping table will be needed of these
instances.
Ambiguities stem from the fact that the application of the proposed algorithm to ICD values from 0001
to 112 yield IIQ values of 01 to 34 in conflict with the values allowed to date. Also, the values 855 and
1295 conflict with NR and ZZ. A method for limiting the number of ambiguities is to restrict the
permitted signs to 0 and the 26 letters. ICD values 396 and 728 would have to be avoided.
The conversion algorithm is therefore :
N10 = a x 27 + b
where N10 is the ICD value, a and b are respectively the left and right characters of the IIQ value. A
and b take their values from the set {0, A to Z}.
This conversion scheme is used in the examples of clause 5.
registered organization identifier
The registered organization identifier is coded in data element ISA06 (Interchange Sender ID) orISA08 (Interchange Receiver ID).
One or more check characters may be added to the end of the registered organization identifier. Thealgorithm for deriving the check character is registration scheme dependent.
organization - free part
The organization - free part is coded as a continuation of the registered organization identifier in dataelement ISA06 (Interchange Sender ID) or ISA08 (Interchange Receiver ID).
One or more check characters may be added to the end of the registered organization identifier. Thealgorithm for deriving the check character is registration scheme dependent and may use both theregistered organization identifier and the organization - free part as input.
Application of EC Identifiers in X.509 Public Key Certificates
C 1 What is an EDIRA Business Identifier
An organization like a Chamber of commerce usually uses a registration-scheme toidentify its customers. Within this identification domain the identification isunambiguous. If such an identifier is preceded by a value of an International CodeDesignator (ICD) issued by the International Standards Organization (ISO). Thus, theidentifier allocated to a specific customer of this organization becomes unambiguousworld-wide. Such an ICD value can be requested at EDIRA to be used as a prefix to aregistration scheme. If registration-scheme fulfils EDIRA’s quality requirementsEDIRA will request an ICD value at ISO for this organization. At ISO the scheme willbe registered as EDIRA compliant.
C 2 Implementation
There are two possible, non-exclusive ways to implement an EC Identifier in an X.509certificate: 1. An extension is defined by using the EBIC as an object identifier (OID). If the EBIC is equal to an iso-6523 compliant ICD, the OID has the form { iso(1)identified-organization(3) corresponding-ICD(nnnn) }.
The extension should be marked non-critical.
The registered identifier is placed in the value field of this extension. Thisvalue field may contain additional leading characters. In this case thebeginning of the registered identifier must be marked by an exclamationmark(‘!’).
Recommended character encoding for the extension is IA5String, or, in caseof a character set exceeding ASCII, UTF8String.
2. The EC identifier is written into the Distinguished Name of the certificate holder. The recommended attribute type is organisational unit(OU). Anexclamation mark (‘!’) must be used as a separator between the EBIC and theregistered identifier.
An ICD may be prolonged to 4 digits by adding leading zeroes.
C 3 Major advantages
(a) The EDIRA Business Identifier makes the Distinguished Name (DN) unique.
(b) The same entity specified in the alphabetic part of the DN can have several certificates for several purposes by specifying the organization part of theEDIRA Business Identifier.
(c) In any computer application which deals automatically with certificates, it is convenient to use the EDIRA Business Identifier instead of the entire DN.
(d) Especially, the EDIRA Business Identifier can be used as an identifier of a sender or recipient in classical EDI interchanges.
(e) The EDIRA Business Identifier can be inherited by a new certificate issued to the same certificate holder. Thus, a computer application does not need anychanges.
(f) The identifier issued to an organization is securely linked with the credentials of this organization by the digital signature of the certification Authority.
(g) The EDIRA Business Identifier can be used for the management of certificates at corporate customers of the certification Authority. Certificate managementwill become an important security issue in every company.
The EDIRA Business Identifier is a powerful instrument for issuers and holders of public key
certificates.
FORMULATED AS AN IDEA HOW IT COULD WORK; not yet defined correctly:see: Collaboration-Protocol Profile and Agreement Specification, Version 1.0ebXML Trading-Partners Team, 10 May 2001,7.5 Party element “It is RECOMMENDED that the value of the type attribute be a URN that defines a
namespace for the value of the PartyId element. Typically, the URN would be registered as a
well-known directory of organization identifiers.
The following example illustrates two URI references.
<PartyId type = "uriReference">urn:duns:123456789</PartyId><PartyId type = "uriReference">urn:www.example.com</PartyId> The first example is the URN for the Party's DUNS number, assuming that Dun andBradstreet has registered a URN for DUNS numbers with the Internet Assigned NumbersAuthority (IANA). The last field is the DUNS number of the organization.
The second example shows an arbitrary URN. This might be a URN that the Party hasregistered with IANA to identify itself directly.” EDIRA or “ISO6523” registers the name with IANA. Then the same example could be written:<PartyId type = "uriReference">urn:iso6523:0060:123456789</PartyId><PartyId type = "uriReference">urn:edira:0060:123456789</PartyId>(0060 is the ICD value of DUNS; the syntax of ID to be discussed) FORMULATED AS AN IDEA HOW IT COULD WORK; not yet defined correctly:see “EDIRA” or “ISO6523” could be used as a global location identifier being an attribute of anentity in the “Universal Description Discovery & Integration (UDDI)” registry.

Source: http://www.uninfo.it:8888/TC154/TC154private/154n381_iso-cd22208-1_DRAFT.pdf