[urn] Re: Informal URN Namespace Registration Request for Tr ivore Corp.

Hello Ted!
Good idea. We might even inspirate from informal URNs by using "urn-#" for this. Term "customer" is too loaded in my mind. Same for term "user". Term "organisation", or just "org" might work, thus "org-#".
my best, Kari


________________________________
From: Ted Hardie <[email protected]>
Sent: 12 January 2026 12:09
To: Kari Mattsson (Trivore) <[email protected]>
Cc: Peter Saint-Andre <[email protected]>; [email protected] <[email protected]>; URN-admin <[email protected]>
Subject: Re: [urn] Re: Informal URN Namespace Registration Request for Trivore Corp.

Hi Kari,

I think a sub namespace per customer would help here.  One thing I might suggest, though, is that you consider making that a customer number rather than name.  Should your customers merge or spin-off later, that will facilitate assigning new sub namespace to the successor entities (since there might otherwise be disagreements on who can make assignments in the original).

best regards,

Ted

On Sun, Jan 11, 2026 at 4:36 PM Kari Mattsson (Trivore) <[email protected]<mailto:[email protected]>> wrote:
Hello Ted!

You raised a good question we do not yet have a final answer, and it is why for time being, we do not allow for users to create their own scopes or claims. Only the ones coming with the product are for now supoprted.

An initial internal idea was defining a unique sub namespace for each customer needing their own scopes/claims.

As an example,
urn:trivore:id:scope:customerName:<NSS>
urn:trivore:id:claim:customerName:<NSS>

We would have to keep track of those customerNames.
That would be feasible as we currently know our customers, but nothing is decided yet.
Once we have answer for this, we will amend the application and update documentation.
What ever is defined, must be built to last.

Thanks,

Kari

________________________________
From: Ted Hardie <[email protected]<mailto:[email protected]>>
Sent: 08 January 2026 18:21
To: Kari Mattsson (Trivore) <[email protected]<mailto:[email protected]>>
Cc: Peter Saint-Andre <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; URN-admin <[email protected]<mailto:[email protected]>>
Subject: Re: [urn] Re: Informal URN Namespace Registration Request for Trivore Corp.

Howdy,

If customers can create the claims and scopes, how do you insure that they maintain the uniqueness properties of a URN?

regards,

Ted Hardie

On Thu, Jan 8, 2026 at 3:40 PM Kari Mattsson (Trivore) <[email protected]<mailto:[email protected]>> wrote:
Dear Peter!

We originally aimed for formal registration for NID "trivore", and thus namespace "urn:trivore:<NSS>".
You've found a remembrance of that in the sections Documentation and IANA Considerations. Good catch 🙂

Truth is, we'd like to have a formal namespace "trivore" registered.
I'm attaching an amended application to this mail with just one change:
"urn-#" => "trivore".

For the real life usage of URNs, I'd like to give you more understanding.
We have  an OIDC certified IdP "Trivore ID", and an IAM product built on top of that.
OIDC has concept of Claims and Scopes. And we have so many of those built in, and users may also create their own.
Current list is not very beautiful: https://id.trivore.com/apidoc/oidc
We are changing those to be URN formatted, thus this application.
urn:trivore:id:scope:
urn:trivore:id:claim:
etc. — I hope you get the idea. Those will be public and publicly documented.

Attachment covers this purpose also better. Thanks for pointing this out!
I also touched other points you noted. Beneficial clarifications, thanks!

br, Kari

~ ~ ~ refreshed application:


URN Namespace Registration for Trivore Corp.


Namespace Identifier (NID):
trivore


Registration information:
Version: 1
Revision information: 1
Date: 2026-01-02


Declared registrant of the namespace:
Organization: Trivore Corp.
Contact Role: URN Administrator, urn-admin&trivore.com<http://trivore.com>
Contact Person: Kari Mattsson (URN Administrator)
Address: Helsinginkatu 15, 20500 Turku, Finland
Website: https://www.trivore.com/


Purpose:
This namespace is intended to provide persistent, globally unique, location-independent identifiers for resources defined and managed by the declared registrant. The identifiers are not intended to resolve to network locations.
Main usage is standardising technical definitions of Trivore products, initially Trivore ID OIDC Scopes and Claims, and similar technical definitions for Trivore's IAM product. Long-term purpose is to have coherent definitions.


Syntax:
URNs in this namespace follow the syntax:
urn:trivore:<NSS>

The Namespace Specific String (NSS) is defined as:
<NSS> = <resource-type> ":" <resource-id>
Where <resource-type> and <resource-id> consist of ASCII letters, digits, and the characters “-”, “_”, and “.”.

Maximum length for resource-id is 256 characters.


Namespace semantics:
Each URN identifies exactly one logical resource defined by the registrant. The identifiers are opaque and do not embed personal data.


Assignment:
URNs are assigned exclusively by the declared registrant. Each identifier is guaranteed to be unique within the namespace. Reassignment is not permitted.


Persistence:
URNs in this namespace are intended to be persistent. Once assigned, an identifier will not be reused.


Resolution:
No resolution mechanism is defined for this namespace.


Lexical equivalence:
Lexical equivalence follows the rules defined in RFC 8141.


Security and privacy considerations:
The namespace does not include secrets, authentication material, or personally identifiable information (PII). Identifiers must not be used as access control mechanisms. The namespace does not encode personal data, and correlation risks are minimized by avoiding meaningful identifiers.


Interoperability:
No specific mechanisms are defined to support interoperability with other systems or namespaces. The identifiers are primarily intended for internal use and management by the registrant.


Documentation:
No external documentation is currently provided. This registration document is the primary documentation for the "trivore" namespace.


IANA considerations:
This document requests the registration of the Formal URN Namespace Identifier “trivore”.



________________________________
From: Peter Saint-Andre <[email protected]<mailto:[email protected]>>
Sent: 06 January 2026 19:34
To: Kari Mattsson (Trivore) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
Cc: URN-admin <[email protected]<mailto:[email protected]>>
Subject: Re: [urn] Informal URN Namespace Registration Request for Trivore Corp.

Hi Kari,

Thanks for sending this registration request. Here are a few thoughts
and points of feedback.

I'm curious why Trivore wishes to register an informal namespace (which
would likely be urn:urn-9) instead of a formal namespace (e.g.,
urn:trivore). There really isn't a big difference, but we like to
understand our customers. :-) Also, under "Documentation" and "IANA
Considerations" the registration mentions "the 'trivore' namespace" and
"the Informal URN Namespace Identifier 'trivore'" but those phrases are
inconsistent with the request for an informal namespace identifier.
Please clarify. We are certainly open to registering a formal namespace.

Under "Purpose" the phrase "identifiers for resources" is rather vague.
Perhaps you could explain the purpose in more detail, e.g., what kind of
resources will be identified. A good example of a corporate registration
is this one:

https://www.iana.org/assignments/urn-formal/stalwart

Under "Syntax", are there length limits on the resource-id construct?

Under "Resolution" I think you can remove the second sentence.

Other review team members might have further comments.

Best Regards,

Peter

On 1/5/26 5:53 AM, Kari Mattsson (Trivore) wrote:
> Dear IANA URN Namespace Registration Team / mailing list,
>
> (As requested by the registration team, I'll mail this to the list.)
>
> I would like to request the registration of a new Informal URN Namespace
> Identifier (NID) in accordance with RFC 8141.
>
>
> URN Namespace Registration for Trivore Corp.
>
>
> Namespace Identifier (NID):
> urn-#
>
>
> Registration information:
> Version: 1
> Revision information: 1
> Date: 2026-01-01
>
>
> Declared registrant of the namespace:
> Organization: Trivore Corp.
> Contact Role: URN Administrator, [email protected]<mailto:[email protected]>
> Contact Person: Kari Mattsson (URN Administrator)
> Address: Helsinginkatu 15, 20500 Turku, Finland
> Website: https://www.trivore.com/
>
>
> Purpose:
> This namespace is intended to provide persistent, globally unique,
> location-independent identifiers for resources defined and managed by
> the declared registrant. The identifiers are not intended to resolve to
> network locations.
>
>
> Syntax:
> URNs in this namespace follow the syntax:
> urn:urn-#:<NSS>
>
> The Namespace Specific String (NSS) is defined as:
> <NSS> = <resource-type> ":" <resource-id>
> Where <resource-type> and <resource-id> consist of ASCII letters,
> digits, and the characters “-”, “_”, and “.”.
>
>
> Namespace semantics:
> Each URN identifies exactly one logical resource defined by the
> registrant. The identifiers are opaque and do not embed personal data.
>
>
> Assignment:
> URNs are assigned exclusively by the declared registrant. Each
> identifier is guaranteed to be unique within the namespace. Reassignment
> is not permitted.
>
>
> Persistence:
> URNs in this namespace are intended to be persistent. Once assigned, an
> identifier will not be reused.
>
>
> Resolution:
> No resolution mechanism is defined for this namespace. Any resolution
> services, if provided, are outside the scope of this registration.
>
>
> Lexical equivalence:
> Lexical equivalence follows the rules defined in RFC 8141.
>
>
> Security and privacy considerations:
> The namespace does not include secrets, authentication material, or
> personally identifiable information (PII). Identifiers must not be used
> as access control mechanisms. The namespace does not encode personal
> data, and correlation risks are minimized by avoiding meaningful
> identifiers.
>
>
> Interoperability:
> No specific mechanisms are defined to support interoperability with
> other systems or namespaces. The identifiers are primarily intended for
> internal use and management by the registrant.
>
>
> Documentation:
> No external documentation is currently provided. This registration
> document is the primary documentation for the "trivore" namespace.
>
>
> IANA considerations:
> This document requests the registration of the Informal URN Namespace
> Identifier “trivore”.
>
>
> Please let me know if any additional information or clarification is
> required.
>
> Kind regards,
> Kari Mattsson
> URN Administrator
> Trivore Corp.
> [email protected]<mailto:[email protected]>
>
>
> _______________________________________________
> urn mailing list -- [email protected]<mailto:[email protected]>
> To unsubscribe send an email to [email protected]<mailto:[email protected]>

_______________________________________________
urn mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>

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