This is the UUID namespace for the ARPA2 / InternetWide project.

Allocations will be assigned to any project that requires it. We generate the UUIDs using the Python UUID library, invoking

import uuid

def prj2uuid (prjname):
    return uuid.uuid3 (uuid.NAMESPACE_DNS, prjname.strip ().lower () + '')

prjname = 'whatever'
assert (prj2uuid (prjname) == uuid.UUID('cd146e75-6fb4-3837-8559-c8d513e60eec'))

We always represent UUIDs in the lowercase form, for compatibility with LDAP notation. The UUID is consistently the same when generated again at a later moment.

Projects can reserve multiple names by defining sub-labels under their name, in DNS style. Such sub-labels are best also reserved here.

Assignments Made

Projects are kindly requested to help maintain this listing; assignments are final but only after they have been listed!

IdentityHub ("root control" over a domain)

53281a7c-2c69-3d49-b12f-590e0a2f54bc == uid.domain.identityhub

IdentityHub will use the uid.domain.identityhub UUID in LDAP as a resourceClassUUID value. In addition to this, the domain name in lowercase, dot-separated but not dot-terminated format is used as a resourceInstanceKey. These attributes are stored in the nodes associatedDomain=,ou=IdentityHub,,ou=InternetWide for various domains.

In addition to this resource instance identity, the same objects are setup as accessControlledObject to allow accessControlLine attributes that express who may create, delete, own and read or write uid values (currently for users, pseudonyms, groups and roles). This access control does not express the right to add sub-identities (currently for aliases, group members or role occupants) because that is always the prerogative of the owner of the base identity, just like editing their own description.


Since this effectively bootstraps the domain, the same ACL is used to control the ability to edit the domain description information, including this ACL itself. In other words, this is pretty much the "root account" for a domain owner.

The nodes are not identified as a resourceInstanceKey but by their associatedDomain RDN because that is the pattern to be used for all services. Many other services do not share the same resource and ACL setup, and if they define access control then it will be of another nature. What they all have in common however, is the use of a domain name.


904dfdb5-6b34-3818-b580-b9a0b4f7e7a9 == reservoir

reservoir will use the reservoir UUID in LDAP as a resourceClassUUID value. This attribute is stored in the top node(s) for the Reservoir application, namely the client-domain nodes associatedDomain=,ou=Reservoir,,ou=InternetWide and in the Resource Collection objects that fall directly underneath that. Only the Resource Collection has an additional resourceInstanceKey value with a random UUID, and this will be used as the resins= RDN for that object. This UUID is written in textual form, with lowercase letters.


Wrappers around the Reservoir, such as for WebDAV, use this allocated UUID to match the Reservoir application and avoid seeing results from other applications.

The actual Resource objects are found immediately under a Resource Collection object, and the RDN of the latter is used to quickly find the appropriate ACL. When access is granted, the LDAP search results will also be used to construct paths in Riak KV.

Remote PKCS #11

3761bc67-c862-3ef3-83f0-0dc614b76328 == remote-pkcs11

Remote PKCS #11 will use the remote-pkcs11 UUID in LDAP as a resourceClassUUID value. This attribute is stored alongside another UUID in the same lowercase text representation that functions as a resourceInstanceKey value to identify a layer of objects in the Remote PKCS #11 service.


Layers in Remote PKCS #11 are not just created for users and groups, but also for services. These introduce the need for an independent identification mechanism. Users and groups should relate to these identities in LDAP.