Security model

This is an outline of the planned security model. It is subject to change as the implementation evolves.

Authentication and identity

Authentication of users will be performed using OpenID Authentication 2.0 . This is intended to be compatible with likely future government authentication schemes, enables access to widespread existing authentication services such as Google and enables us to provide authentication in the Registry with having to store credentials or personal information locally thus reducing the burden of operating a registry service.

The internal identifier for a user will be the identity URI provided by the OpenID authority. For example, authentication via a generic Google account yields an identity URI of the form https://www.google.com/accounts/o8/id?id=AItOawnQBYnsRksvzmoKfzHW3NX5_EVBQ7DkbhI whereas authentication using an individuals Google profile yields a URI which resolves to the users profile page such as https://profiles.google.com/114719444327647609228 .

When an administrator needs to associate a role with a user we need a human readable alias. For the proof of concept we will use a human readable name for user obtained from the OpenID provider using OpenID Attribute Exchange 1.0 . The precise set of name attributes available varies by provider. The proof of concept will assume attributes compatible with the Google OpenID attribute schema, viz. firstname and lastname.

When assigning roles is up to the granter to satisfy themselves that the identity to which they are granting role privileges corresponds to the intended real world person. For an OpenID provider which provides public access to profile information (e.g. individual Google + profile pages) this may be easy. For other providers (e.g. general Google account) then a manager may need to take additional steps. Such identity verification is out of scope of the proof of concept.

Permissions

The set of actions for which permissions can be granted or denied are:

• Register an item in a register
• Update an item
• Status update of an item within life-cycle constraints
• Force a status change outside the life-cycle
• Grant administrator role
• Grant register manager role
• Grant item maintainer role

All read actions are assumed to be uniformly available. No login is required to read any part of the registry. So a separate read permission is not currently proposed.

Delete is not currently a separate permission because it just corresponds to a status change.

This permission set could be further subdivided in the future. For example, one might conceivably want to grant permission to register a simple item but not a sub-register. Or one might want to grant different permissions over different status transitions. However, for the proof of concept we have no use cases for such finer grain permissions.

Note that a single API action might require multiple permissions. An API call can both register/update an item and can change its status either explicitly (in the request parameters) or implicitly (by including a reg:status value on a reg:ResisterItem in the payload).

There will one pseudo identifier guest corresponding to any access. This can used to grant
h2. Roles

We propose to group these permissions into four roles.

Role name	Applies to	Permissions
Administrator	Whole registry	All permissions
Register manager	A specific register and its contained subtree	Register Update Status update Grant item maintainer and register manager
Item maintainer	A single non-register item	Update Grant item maintainer
Experimenter	Specific register	Register Update Status update

The first three roles are intended to be the primary operating roles. The experimenter role is designed allow relatively free access to granted to register sub-trees to allow experimentation with basic registry operation.

Role/location bindings

The administrator roles are global to a given Registry instance.

The other roles are associated with a location in the register tree, either a Register or an individual item. Each role binding also applies to all items below the binding point in the tree. Thus an individual granted Register Manager role for the root register would have manager privileges for every register and item within the entire registry.

A separate binding store is used to hold the master information which associates a location (corresponding to a RegisterItem) to set of identity x role pairs. This master binding information can be reflected into the registry metadata through use of reg:manager for registers, and through a extension property for item maintainer (e.g. reg:maintainer). However, the registry triple store is not the master security store so that compromise of the store doesn’t itself result in the ability to grant new privileges.

Non-browser access

API operations, other than read, will in general require an authenticated session. Custom tools can be provided for this but it is still possible to use generic command line tools. An operator would need to authenticate an OpenID session using either the registry itself or a custom tool. This would result in a session cookie which can be provided to curl or other command line tools.