[urn] Re: Request to register urn:glue - Additional Observ ations from Affected Ecosystems

Hi Tom & All,

Here is some more technical detail:

https://www.federalregister.gov/documents/2025/08/28/2025-16547/agency-information-collection-activities-revision-global-business-identifier-gbi

If we try to pull global business identifiers for DUNS, GS1 and LEIs as
URNs, this is what we have so far:

- urn:epc:id:sgln:0012345.11111.0 -
https://datatracker.ietf.org/doc/html/rfc5134 -
https://github.com/search?q=urn%3Aepc%3Aid%3Asgln&type=code
- urn:LEI:7LTWFZYICNSX8D621K86 -
https://www.iana.org/assignments/urn-formal/lei /
https://search.gleif.org/#/record/984500C1ED3886F2FF45 / -
https://github.com/search?q=urn%3Alei%3A&type=code
- urn:duns:002372413:annual-report-1997 -
https://datatracker.ietf.org/doc/html/rfc2168 -
https://github.com/search?q=urn%3Aduns%3A&type=code

For contrast, here is an identifier based on URLs:

- https://opencorporates.com/companies/us_va/11014970 -
https://github.com/search?q=https%3A%2F%2Fopencorporates.com%2Fcompanies%2F&type=code

GitHub links are provided as a proxy for adoption/traction; take those with
as much salt as you like.

As background, most legal entity registries have varying degrees of quality
and global coverage, which consistently requires implementers to use more
than one.

What I like about GLUE is that it provides a path for any implementer to
register names for entities handled the same way as the identifiers above.
In software implementations, validation can apply to "urn:glue" or "glue:"
or "<UTF-8 Prefix>"; dispatch or routing can then provide equivalent
support for entity identifiers from different systems.

I'll note that https://datatracker.ietf.org/doc/html/rfc7320 is very
relevant to this discussion, as is the identifier class in
https://datatracker.ietf.org/doc/html/rfc7564

Here is my desired outcome:

- Standard representation for entity identifiers that is not controlled by
a single authority -- except perhaps IANA : )
- Some imposed structure... <UTF-8 Prefix> above is just to trigger JCK and
PSA : )
- Open and easy process for creating new entity identifiers without the
risk of collisions; IANA excels at this
- Compatibility with existing identifier parsing systems -- software &
people already understand URIs

urn:epc:id:sgln:0012345.11111.0 -> glue:*sgln*:0012345.11111.0
urn:LEI:7LTWFZYICNSX8D621K86 -> glue:*lei*:7LTWFZYICNSX8D621K86
urn:duns:002372413:annual-report-1997 -> glue:*duns*
:002372413:annual-report-1997

Spec Required -> glue:*new-registry-with-different-coverage*
:da531da4-54c4-47e5-84ab-1fbc400f3173

The underlined part explains why a collision resistant registry is
required; the non-underlined part is the real-world observation motivating
the draft.

I don't think the glue registry's (URN or URI) initial contents should
include any identifiers not supported by their natural authorities, and
yes, this puts some burden on DEs.
See also: https://www.iana.org/assignments/uri-schemes/prov/git (Yes, git
is still provisional, but at least it's registered : )

If URN experts think URIs are a better fit, and URI experts agree that
seems like a fine outcome to me.
If both sides think a UTF-8 prefix and suffix with a registry for prefixes
is a better approach, that would also be good to know, but I'll probably
have more to say if that's the case : )

Sorry for the long email,

OS




On Sat, Mar 28, 2026 at 7:47 AM Tom Roberts <[email protected]> wrote:

> All,
>
> I appreciate the thoughtful responses since my earlier email, and I
> recognise that Michael's frustration is understandable. My intent remains
> constructive. I write again only because a few additional points have come
> to light that may be useful to the designated experts as they work toward a
> decision.
>
> Since my earlier message, I have spoken with Chris Day, one of the lead
> architects of ISO 20022 (SWIFT messaging), who now works with GS1. With his
> permission, I can share that GS1 would not support this registration. This
> is significant given that GS1 identifiers including the GLN are among the
> authority registrations proposed in Section 7.1.2.1 of the draft.
> Introducing a parallel urn:glue: path for those identifiers, without the
> knowledge or support of the organisations that govern them, risks
> undermining an infrastructure that has taken years and considerable
> investment to build.
>
> On the question of resolution, I want to offer a practical perspective
> from our own experience. In the SDMX community, where I am a technical
> working group member, we made a deliberate decision to build a resolver
> service https://urn.sdmx.io ahead of our URN registration because we
> understood the operational value resolution provides to our members: the
> BIS, ECB, Eurostat, IMF, OECD, the UN, and the World Bank, among others.
> Resolution is not a theoretical nicety; it is what makes an identifier
> operationally useful within a governed ecosystem.
>
> This brings me to what I believe is a substantive tension in the GLUE
> draft. Section 7.2.1 states that GLUE URNs provide "a globally unique
> equivalent to identifiers within those local namespaces," yet the same
> section states that resolution is not performed. To be clear, the concern
> is not that URNs are obligated to resolve, RFC 8141 is clear on that point.
> The concern is that GLUE claims equivalence to identifiers from systems
> that may operate resolution infrastructure, while providing none of its
> own. GLEIF, for example, provides resolution services for Legal Entity
> Identifiers through the Global LEI Index, a public platform offering
> web-based lookup, API access, and data mappings that support verification,
> KYC, and compliance workflows worldwide. Introducing a parallel identifier
> that claims equivalence to an LEI but offers no comparable resolution path
> creates genuine ambiguity for implementers operating in those ecosystems.
>
> Ted Hardie's suggestion of a glue: URI scheme rather than urn:glue: is
> worth serious consideration, and I note that Orie has expressed a similar
> view. I do not hold a strong technical opinion on that path, but it appears
> to address several of the concerns raised here without abandoning the
> underlying goals of the work.
>
> I defer entirely to the designated experts on the appropriate outcome, but
> I respectfully suggest that reaching out to the originating authorities,
> GLEIF, GS1 and the relevant ISO technical committees before proceeding
> would serve everyone's interests. Not as a formal condition, but as a
> matter of professional courtesy and practical prudence.
>
> Best regards from Prague,
>
>
> <http://smartxdata.com/>
>
> *Tom Roberts*
>
> *Chief Data Officer / Founder*
>
> *ISO 17369 TWG Member*
>
> *Eurofiling Member*
>
> *Mobile **CZ: +420 773 532 216*
>
> *Mobile US: +1 689-837-7529*
>
> *Email: [email protected] <[email protected]>*
>
>
>
>
>  CONFIDENTIAL COMMUNICATION: This email message and any attachment may
> contain privileged and confidential information intended only for the use
> of the individual or entity to which the email is addressed. If the reader
> of this message is not the intended recipient or the employee or agent
> responsible to deliver it to the intended recipient, that person is hereby
> notified that any dissemination, distribution or copying of this
> communication is prohibited. If you have received this communication in
> error, please notify us as soon as possible by telephone (collect calls
> will be accepted). Thank you for your cooperation and assistance.
>
> <https://twitter.com/macktony>
>
>
>
>
>
> On Fri, Mar 27, 2026 at 6:32 PM Ted Hardie <[email protected]> wrote:
>
>> Hi Michael,
>>
>> I understand your frustration at this late intervention, and it is
>> regrettable that the review was not solicited much earlier in the life of
>> the development of the GLUE proposal.  When there isn't an active working
>> group, it can be hard to ensure that this kind of cross-working group
>> review occurs.  Despite the timing, however, the concerns Dale and others
>> have raised are significant.  If you review RFC 8141, will you see that a
>> core principle is that the combination of NID and NSS must result in an
>> identifier that is globally unique:
>>
>>    The NSS is a string, unique within a URN namespace, that is assigned
>>    and managed in a consistent way and that conforms to the definition
>>    of the relevant URN namespace.  The combination of the NID (unique
>>    across the entire "urn" scheme) and the NSS (unique within the URN
>>    namespace) ensures that the resulting URN is globally unique.
>>
>> Historically, that assurance has been derived from the registrant of the
>> NID being the authority which issues the namespace specific strings
>> associated with that NID.  In any proposal where that is not the case,
>> there is a risk that the actual issuing authority's approach to uniqueness
>> may change over time, resulting in a combination that does not meet the
>> goals of a URN.
>>
>> In your proposal, the registration of "GLUE Authority Identifier URN"s is
>> meant to replace the normal relationship between the NID registrant and NSS
>> by providing for registration of external authorities, who the designated
>> experts believe will behave in a way consistent with the URN guidelines.
>>  The guidelines in the document do not contain advice to the experts on how
>> to evaluate that, nor does it contain any guidelines on how to invalidate a
>> GLUE Authority Identifier if the authority ceases to issue identifiers that
>> would conform (imagine for a moment that Dun and Bradstreet decided to
>> reuse DUNS numbers after the original entity had been defunct for 50
>> years--this would be rational for some use cases, but would invalidate
>> their use as URNs).
>>
>> In a lot of ways your proposal echos the approach taken by the DOI
>> foundation (see http://www.doi.org/registration_agencies.htm for a list
>> of their registration agencies).  That suggests to me that one way forward
>> here might be to shift this registration from a URN NID registration to a
>> URI scheme registration, which would parallel how the DOI foundation moved
>> forward when faced with similar concerns.  You can see the details of their
>> scheme registration here:
>> https://www.doi.org/resources/DOI_URI_Scheme.pdf.
>>
>> The change in your document would be to shift from urn:glue to glue: as
>> the start of the identifier; you could otherwise maintain the same syntax
>> and the same approach to registering subsidiary GLUE Authority
>> Identifiers.  The difference would be that the document would need to
>> describe how the glue URI achieved uniqueness and over what scope, but it
>> could echo those statements from the URN documents which matched your
>> intent.
>>
>> Just a suggestion, of course, but it does seem to me like the quickest
>> way to move forward, even if it does mean a trip back to the working group
>> to approve the change and a review by the URI scheme registration list and
>> designated experts.  I am not one of the designated experts, but I am on
>> that list and I believe that with a pointer to the doi scheme registration
>> and an explanation of the issue that this could move forward as a URI
>> scheme.
>>
>> regards,
>>
>> Ted Hardie
>>
>> On Fri, Mar 27, 2026 at 2:54 PM Michael Jones <
>> [email protected]> wrote:
>>
>>> Hi Dale,
>>>
>>> Thanks for letting me the know the status of this application, Dale.
>>> The whole point of the GLUE draft is to "incorporate ... identifiers
>>> controlled by other organizations" into the URN namespace.  This enables
>>> URNs to be used in protocols to refer to organizations, whether the
>>> identifiers controlled by other organizations already have a URN
>>> representation or not.  That's exactly why the working group took on this
>>> work.
>>>
>>> This isn't academic.  There's intent to use it in multiple independent
>>> use cases.  For instance, ISO/IEC 6523 identifiers were included in the
>>> GLUE URN space because of a desire to use it for Swedish government use
>>> cases, per
>>> https://github.com/ietf-wg-spice/draft-ietf-spice-glue-id/issues/51.
>>> GLUE was originally motivated by cross-border trade use cases.
>>>
>>> Indeed, the description of URNs in
>>> https://www.rfc-editor.org/rfc/rfc8141#section-6.3 seems to anticipate
>>> uses of URNs incorporating identifiers from other standards:
>>>    The IETF recognizes that situations will arise in which URN
>>>    namespaces will be created to either embed existing and established
>>>    standards, particularly identifier standards
>>> That's exactly what GLUE does - so that URNs can be used for those
>>> namespaces that previously were not represented as URNs.
>>>
>>> This is an aside, but the parts of GLUE that one could reasonably say
>>> are unnecessary are where URNs already exist for the identifiers.  LEI URNs
>>> are such a case, per
>>> https://www.ietf.org/archive/id/draft-ietf-spice-glue-id-08.html#name-lei-urns.
>>> The authors could consider dropping registrations of the arguably
>>> unnecessary duplicative GLUE URNs if that would address the Designated
>>> Expert's concerns.
>>>
>>> Having every organizational identifier from any source be referenceable
>>> as a URN is the point.  Please let's get that done.
>>>
>>> This note is written in the spirit of
>>> https://www.rfc-editor.org/rfc/rfc8141#section-6.2:
>>>    Because naming can be difficult and contentious, URN namespace
>>>    registrants and the Designated Experts are strongly encouraged to
>>>    work together in a spirit of good faith and mutual understanding to
>>>    achieve rough consensus (see [RFC7282]) on handling registration
>>>    requests.
>>>
>>> Please work with us to meet the need for URNs to be usable to refer to
>>> organizational identifiers from any source.
>>>
>>>                                 Thank you,
>>>                                 -- Mike
>>>
>>> -----Original Message-----
>>> From: Dale R. Worley <[email protected]>
>>> Sent: Thursday, March 26, 2026 6:58 PM
>>> To: Michael Jones <[email protected]>
>>> Cc: [email protected]; [email protected]; [email protected];
>>> [email protected]; [email protected]
>>> Subject: Re: [urn] Request to register urn:glue
>>>
>>> Michael Jones <[email protected]> writes:
>>> > Touching base on this.  The authors addressed the review comments from
>>> > the designated experts.  The spec has completed working group, IETF,
>>> > and IESG review.  Publication as an RFC is currently blocked until the
>>> > state changes to "IANA OK".  Can one of you please approve the
>>> > registration so it changes to "IANA OK"?
>>>
>>> Currently the URN expert group is running into the problem that we
>>> disagree with -- or at least, have unresolved concerns with -- the
>>> *concept* of the GLUE namespace, specifically, that it incorporates a
>>> number of identifiers controlled by other organizations.
>>>
>>> The more generalized discussion is in the thread
>>>
>>> https://mailarchive.ietf.org/arch/browse/urn/?gbt=1&index=KjzL-lRp3zCYw51AATq993ifAmo
>>>
>>> Dale
>>>
>>> _______________________________________________
>>> urn mailing list -- [email protected]
>>> To unsubscribe send an email to [email protected]
>>>
>> _______________________________________________
>> urn mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> Virus-free.www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#m_6105029753241138626_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

_______________________________________________
urn mailing list -- [email protected]
To unsubscribe send an email to [email protected]