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 () + '.uuid.arpa2.org') 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.
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
for various domains.
In addition to this resource instance identity, the same objects are
accessControlledObject to allow
that express who may create, delete, own and read or write
(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
resourceInstanceKeybut by their
associatedDomainRDN 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
in LDAP as a
resourceClassUUID value. This attribute is stored in the top
node(s) for the Reservoir application, namely the client-domain nodes
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.