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.

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,o=arpa2.net,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.

Informative:

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.

Reservoir

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,o=arpa2.net,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.

Informative:

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.

Informative:

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.

HTTP Authorisation

7a35d76d-a754-35a6-abe7-757c161f0263 == httpauthz

HTTP Authorisation for a given host name and realm. This will use the httpauthz UUID in LDAP as a resourceClassUUID value. This attribute is stored alongside a resourceInstanceString consisting of the hostname, in lowercase ASCII (possibly using PunyCode xn- nottation for internationalised labels) and with no trailing dot; then a slash character; then the realm name as a literal, case-sensitive string.

Example:

Accessing https://example.com/orvelte as bakker@orvelte.nep in realm Bakkerij, Oven/Front would result in the instance being example.com/Bakkerij, Oven/Front.

Network Service

75461870-1789-33ab-8e96-2736df4ffad7 == networking

The networking Resource Class is intended for access to protected networks. Think of VPN access, where ACL matters may come up to rearrange access control as dynamically as a domain is managed.

Remote Area Network access list

fae43892-2427-3fe0-82d7-082c75bfba4e == welcome.rantast

The welcome.rantast Resource Class is used for access control to a RANtast endpoint. The identities matched are network endpoints, usually of a form +ran0@example.com and these would occur in the ACL for another network endpoint.

Communication Access

b4f0fc38-d4d7-3bb9-ad69-5bf75efc46dd == communication

The `communication' Access Type is used for access control from a remote user to a local user. The Access Name is:

  • A local ARPA2 Identity in canonical form
  • Stripped from signature and its surrounding plusses
  • Users are stripped from plusses and aliases
  • Services are stripped from plusses and arguments

The ACL may introduce constraints to the stripped parts, but these are not part of the lookup procedure in the ACL. The only iteration that is performed on an ACL is to match more abstract forms of a remote user, until one matches, with @. as the most abstract form, serving as a catchall.

Document Access

51af068f-49dd-3fd4-a94d-37052073e98e == document

The document Access Type is used for access control of a remote user to a document. The Access Name either names an explicit volume, otherwise it describes ARPA2 Reservoir.

For ARPA2 Reservoir, the Access Name is:

  • /<colluuid>/, so a Collection UUID in lowercase between two slashes;
  • Resources and further Paths underneath a Collection are reduced to this Collection UUID form;
  • Paths that do not start with /<colluuid>/ lead to default access rights %K; note that this includes the path /<colluuid> without the trailing / too.

For operator-named Volumes, the Access Name is:

  • //<volume>/<path> with no initial slash in the Path and neither slash nor at sign in the <volume>, or
  • //<user>@<volums>/<path> with the same constraints and a lowercase <user> without slash or at sign;
  • Case-insensitive parts should be reduced to lowercase;
  • The general form is a UTF-8 string terminated by a NUL character.

Attribute Access

31232c49-c5b6-3fc4-89ad-f85799af0479 == attribute

The attribute Access Type is used for access control of a (possibly remote) user to attributes. This may be used on top of Document Access, where desired by an application.

This is an attempt to implement privacy laws. Filtering what content may be spread from a certain Access Domain allows privacy regulations to be enforced, and have a clear declaration of what goes out and to whom for users. Access Control would literally implement these legal aspects of a privacy contract (and might even be used to explain this to users in an automatation-friendly form).

The purpose here is to specify attributes such that they need the fewest number of definitions. Attribute types are therefore reduced to a canonical form, meaning to avoid overlap between protocols and type naming schemes.

The Access Name takes the form of a URI. This may well be a non-URL form, so a URN, including the urn:oid: for object identifiers, urn:oasis: for SAML2 attributes, or tag: URIs to uniquely name domain-local definitions.

Procedure. It will generally be necessary to lookup multiple attributes, and not all may be defined. The procedure is as follows:

  1. Portions of the URI that may be in any case should be canonicalised to lowercase form.
  2. Split the URI into a scope and attribute name. The name of an attribute must not be empty. The boundaries may very with the scheme, but the distinction should often be clear. Software may develop to accommodate new schemes and it may reject unknown schemes.
  3. Look for the scope alone, while performing Iteration over the (Remote) Selector. When a record is found it defines (1) the default Access Rights for attributes, and (2) the Selector to use for the actual attributes. If nothing is found, stop now and permit only %V or Visitor rights for any desired attribute name.
  4. Iterate over attribute names under the scope, retrieving Access Rights for the Selector that was found in the previous step.

Examples of scopes are urn:oid: and urn:uuid: and even the tag: URN form that could be used to provide global scope to local names. Most of these schemes are final, though they may carry a version number, so their link to legal behaviour can also be clearly defined.

Note how the procedure only performs Iteration while looking for default attributes. Also note how the procedure favours multiple attribute names in one call, and defines a response for each of them. This requires that the application already makes the split into scope and attribute. This is not a security concern, as long as the scope is indeed found and defines itself as the scope in spite of itself being an incomplete attribute name.

Examples. This general scheme applies in many places.

  • LDAP defines all attributes with an object identifier. Use urn:oid: as the scope.
  • X.509 attribute certificates always use an object identifier. Handle as for LDAP.
  • SAMLv2 uses a variety of URI forms, including urn:oid: and urn:oasis: and possibly many others.

Group Rules

5a1a2596-1763-36bf-a7b2-814ad98083ca == group

The group Policy Rules define flags that describe members, and then follow a sequence of ^member@address triggers that can be used to iterate over targets and to translate a sender address into the sender's member address. The Ruleset for a group are found from an attribute g=<group> which serves as an Access Name to find the group under a domain name.

Zonedata

1b6abbb8-d580-3cbf-a6c6-4000095af382 == zonedata

The zonedata Policy Rules define flags that enable DNS record updates. The Access Name consists of three space-separated words, namely the ownername (lowercase, no trailing dot), the uppercase class (usually IN) and the uppercase RRtype, or ANY to allow any update to those names if no specific rule is set for the RRtype at hand. An example string is lab.example.com IN SSHFP which could be assigned to the sysadmin of that host, or to the SSH service on that host.

OAuth2 signature prefixes

The various strings signed for OAuth2 may end up looking similar. Before interpreting them, and thereby allowing their use in a wrong place, we ensure through signature differentiation what the type of the signed string is. The following forms are distinct because they start with a binary form of the following UUIDs:

  • 79ddc0f7-0758-3cf4-9878-09b0f084b5f2 for an Authorization Code, derived from authorization-code.oauth2.uuid.arpa2.org;
  • deed1209-45dc-33db-81ed-3e68e1911c43 for an Access Token derived from access-token.oauth2.uuid.arpa2.org;
  • 64a7ecda-ff61-3858-a3a1-12a7bff901b1 for a Refresh Token derived from refresh-token.oauth2.uuid.arpa2.org.