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 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.

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).

Roles

We propose to group these permissions into three 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
Guest	Specific register	Register, Update, Status update

Role/location bindings

Non-browser access