Namespace Identifier: LEI Version: 1 Date: 2021-12-22 Registrant: Global Legal Entity Identifier Foundation (GLEIF) St. Alban Vorstadt 5 4002 Basel Switzerland Web: www.gleif.org Email: info&gleif.org Contact person: Ivan Marin Work Phone: +49 69 9074999-22 Cell phone: +34 670 246 255 Email: Ivan.Marin&gleif.org Purpose: 1. The kinds of resources identified by URNs assigned within the URN namespace. Legal entities would be identified by URNs by including the Legal Entity Identifier (LEI), a 20-character, alpha-numeric code based on the ISO 17442 standard developed by the International Organization for Standardization (ISO), in the URN. The LEI code connects to key reference information that enables clear and unique identification of legal entities. Each LEI contains information about an entity's ownership structure and thus answers the questions of 'who is who' and 'who owns whom'. Simply put, the publicly available LEI data pool can be regarded as a global directory, which greatly enhances transparency in the global marketplace. The Global LEI System is managed by the Global Legal Entity Identifier Foundation (GLEIF). LEI codes are restricted to _non-human_ legal entities. Therefore, there are not privacy and interoperability considerations at the very least. Further information regarding LEI can be found here: https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei Indeed the LEI system is already well-developed and standardized and all the LEI namespace registration provides is a systematic way of mapping existing LEIs into URNs. 2. The scope and applicability of the URNs assigned within the URN namespace; this might include information about the community of use (e.g., a particular nation, industry, technology, or organization), whether the assigned URNs will be used on public networks or private networks, etc. The Financial Stability Board (FSB) has reiterated that global LEI adoption underpins "multiple financial stability objectives" such as improved risk management in firms as well as better assessment of micro and macro prudential risks. As a result, it promotes market integrity while containing market abuse and financial fraud. Last but not least, LEI rollout "supports higher quality and accuracy of financial data overall". Consequently, the initial usage of the LEI was in regulatory reporting requirement arising from the 2008 global financial crisis. However, the scope of legal entity types that are eligible to register for LEIs is much broader and the LEI can be used in any industry or domain. In cooperation with its partners in the Global LEI System, the GLEIF continues to focus on further optimizing the quality, reliability and usability of LEI data, empowering market participants to benefit from the wealth of information available with the LEI population. 3. How the intended community (and the Internet community at large) will benefit from using or resolving the assigned URNs. GLEIF has received a request from the co-chairs of the W3C Rights Automation Community Group who want to use the LEI to identify parties involved in the use of market data (exchanges, intermediaries, banks, etc.). The co-chairs specifically have asked if GLEIF would work on developing a URN (RFC 8141) namespace identifier associated with LEIs. 4. How the URN namespace relates to and complements existing URN namespaces, URI schemes, and non-URN identifier systems. An LEI namespace being based on an international standard entity identifier should complement any existing namespace URN/URI and non-URN identifier systems. 5. The kinds of software applications that can use or resolve the assigned URNs (e.g., by differentiating among disparate URN namespaces, identifying resources in a persistent fashion, or meaningfully resolving and accessing services associated with the URN namespace). As stated in point 3 above, GLEIF has received a request from the co-chairs of the W3C Rights Automation Community Group who want to use the LEI to identify parties involved in the use of market data (exchanges, intermediaries, banks etc.), using machine processing. The co-chairs specifically have asked if GLEIF would work on developing a URN (RFC 8141) namespace identifier associated with LEIs. Once a namespace is established for the LEI, this could be used to resolve the LEI to its entity and relationship data for any relevant purpose. 6. Whether resolution services are available or will be available (and, if so, the nature or identity of the services). Examples of q-component and (when they are standardized) r-component semantics and syntax are helpful here, even if detailed definitions are provided elsewhere or later. It is not applicable. For explanation of resolution see "resolution" section below. 7. Whether the URN namespace or its definition is expected to become a constituent part of a standard being developed in the IETF or some other recognized standards body. GLEIF has no plans for the URN namespace or its definition to become part of the ISO 17442 standard itself. Syntax: 1. A description of the structure of URNs within the URN namespace, in conformance with the fundamental URN syntax. The structure might be described in terms of a formal definition (e.g., using ABNF [RFC5234]), an algorithm for generating conformant URNs, or a regular expression for parsing the name into constituent parts; alternatively, the structure might be opaque. The suggested format is (it is not case sensitive): URN:LEI:[20-digit LEI code] For example: urn:LEI:7LTWFZYICNSX8D621K86 That is equivalent to: urn:lei:7LTWFZYICNSX8D621K86 The character set for the LEI is alphanumeric and it consists in uppercase letters and alpha characters A-Z and digits numeric characters 0-9. 2. Any special character encoding rules for assigned URNs (e.g., which character ought to always be used for quotes). There are no special characters in the format (assuming that a colon is not considered a special character) and the format of the LEI is alphanumeric with no special characters. 3. Rules for determining URN-equivalence between two names in the URN namespace. Such rules ought to always have the effect of eliminating false negatives that might otherwise result from comparison. If it is appropriate and helpful, reference can be made to particular equivalence rules defined in the URI specification [RFC3986] or to Section 3 of this document. Examples of URN-equivalence rules include equivalence between uppercase and lowercase characters in the NSS, between hyphenated and non-hyphenated groupings in the name, or between single quotes and double quotes. There may also be namespace-specific special encoding considerations, especially for URNs that contain embedded forms of names from non-URN identifier systems. (Note that these are not normative statements for any kind of best practice related to handling of relationships between characters in general; such statements are limited to one particular URN namespace only.) There will be no names in the URN, only unique, unequivocal 20 character LEI codes. The LEI codes are permanent and never reused. Therefore, equivalence is determined by lexical identity. 4. Any special considerations necessary for conforming with the URN syntax. This is particularly applicable in the case of existing, non-URN identifier systems that are used in the context of URNs. For example, if a non-URN identifier system is used in contexts other than URNs, it might make use of characters that are reserved in the URN syntax. This section ought to note any such characters and outline necessary mappings to conform to URN syntax. Normally, this will be handled by percent-encoding the character as specified in Section 2.1 of the URI specification [RFC3986] and as discussed in Section 1.2.2 of this specification. There is no need for special considerations. 5. Any special considerations for the meaning of q-components (e.g., keywords) or f-components (e.g., predefined terms) in the context of this URN namespace. There is no need for special considerations. Assignment: 1. Mechanisms or authorities for assigning URNs to resources. It ought to make clear whether assignment is completely open (e.g., following a particular procedure such as first-come, first-served (FCFS)), completely closed (e.g., for a private organization), or limited in various ways (e.g., delegated to authorities recognized by a particular organization); if limited, it ought to explain how to become an assigner of names or how to request assignment of names from existing assignment authorities. GLEIF would plan to publish the structure of the LEI URN. Since the structure of an LEI URN would be straightforward, we do not see the need for a registry of URNs for LEIs. It is a prerequisite that a valid LEI exists before creating a LEI URN. The process for issuing a LEI is described here: https://www.gleif.org/en/about-lei/get-an-lei-find-lei-issuing-organizations 2. Methods for ensuring that URNs within the URN namespace are unique. For example, names might be assigned sequentially or in accordance with some well-defined process by a single authority, assignment might be partitioned among delegated authorities that are individually responsible for respecting uniqueness rules, or URNs might be created independently following an algorithm that itself guarantees uniqueness. LEIs themselves are unique with 'A single, unique identifier is assigned to each legal entity.'. So URNs containing unique LEIs also would be unique. Further, steps are taken to ensure uniqueness of LEIs even within a distributed network of LEI assignment as 'Characters 1-4: Prefix used to ensure the uniqueness among codes from LEI issuers (Local Operating Units or LOUs). Security and Privacy: The "Security and Privacy" section of the template describes any potential issues related to security and privacy with regard to assignment, use, and resolution of names within the URN namespace. Examples of such issues include: o The consequences of producing false negatives and false positives during comparison for URN-equivalence (see Section 3.1 of this specification and "Issues in Identifier Comparison for Security Purposes" [RFC6943]). This does not apply as URN-equivalence is not applicable. o Leakage of private information when names are communicated on the public Internet. There will be no leakage of private information as the LEI code and all its reference data are published in the GLEIS is public information. * The potential for directory harvesting. This does not apply because is all data published in the LEI is public data. o Various issues discussed in the guidelines for security considerations in RFCs [RFC3552] and the privacy considerations for Internet protocols [RFC6973]. In particular, note the privacy considerations text for the Global System for Mobile Communications Association (GSMA) / International Mobile station Equipment Identity (IMEI) namespace [RFC7254], which may provide a useful model for such cases. This does not apply. Interoperability: The "Interoperability" section MUST specify any known potential issues related to interoperability. Examples include possible confusion with other URN namespaces, non-URN identifier systems, or URI schemes because of syntax (e.g., percent-encoding of certain characters) or scope (e.g., overlapping areas of interest). If at all possible, concerns that arise during the registration of a URN namespace (e.g., due to the syntax or scope of a non-URN identifier system) should be resolved as part of or in parallel to the registration process. GLEIF does not think there will be any issues related to interoperability. Resolution: The "Resolution" section MUST specify whether resolution mechanisms are intended or anticipated for URNs assigned within the URN namespace. If resolution is intended, then this section SHOULD specify whether the organization that assigns URNs within the URN namespace intends to operate or recommend any resolution services for URNs within that URN namespace. In addition, if the assigning organization intends to implement registration for publicly advertised resolution services (for example, using a system developed in the spirit of the original architectural principles and service descriptions for URN resolution [RFC2276] [RFC2483]), then this section SHOULD list or reference the requirements for being publicly advertised by the assigning organization. In addition, this section SHOULD describe any special considerations for the handling of r-components in the context of this URN namespace. 123456789012345678901234567890123456789012345678901234567890123456789012 The GLEIF API can be used to resolve LEI URNS by extracting the LEI Code from the URN and providing it as a parameter to the GLEIF API. The API gives users of LEIs access to the full LEI Data search engine functionality, including filters, full-text and single-field searches of legal entity and ownership data, and "fuzzy" matching of relevant data fields such as names and addresses. In addition to LEI reference data, the GLEIF API also makes available further related data, e. g. reference data of LEI issuers, code lists used in LEI records and mapped identifiers like BIC or ISIN codes. For example, using the GLEIF API, users can search for LEIs via entity names, find LEIs by BIC code or investigate corporate structures (search for parent and child relationships). Full documentation on the GLEIF API, as well as a demo application, are available with the below links. https://documenter.getpostman.com/view/7679680/SVYrrxuU?version=latest https://api.gleif.org/demo#/query-by-attribute GLEIF API is web based. An example to request the reference data for LEI 7LTWFZYICNSX8D621K86 looks like this: https://api.gleif.org/api/v1/lei-records?filter[lei]=7LTWFZYICNSX8D621K86 Documentation: A pointer to an RFC, a specification published by another standards development organization, or another stable document that provides further information about this URN namespace. The contents of the URN, the LEI, is a standard developed and published by the International Organization for Standardization (ISO). The 17442 standard defines a set of attributes or legal entity reference data that are the most essential elements of identification. The Legal Entity Identifier (LEI) code itself is neutral, with no embedded intelligence regarding the identity of the legal entity itself that could create unnecessary complexity for users. https://www.iso.org/standard/78829.html Key provisions of the ISO 17442 standard are: - enables unique identification globally of entities requiring a legal entity identifier (LEI); - defines a LEI code that contains no embedded intelligence about the legal entity itself; - defines a LEI code that is interoperable with other standards and existing reference data and can be applied globally: - leverages the expertise of ISO/TC 68 in defining and maintaining identifier standards; - defines a LEI scheme that is reliable and a LEI code that is persistent; - defines a LEI scheme that is extensible and free from limitation on use and redistribution. Additional Information: The "Additional Information" section includes information that would be useful to those trying to understand this registration or its relationship to other registrations, such as comparisons to existing URN namespaces that might seem to overlap. This section of the template is optional. Not applicable Revision Information: Description of changes from prior version(s). (Applicable only when earlier registrations have been revised.) Not applicable