Internet DRAFT - draft-hardjono-oauth-decentralized
draft-hardjono-oauth-decentralized
OAuth Working Group T. Hardjono
Internet-Draft MIT
Intended status: Informational March 25, 2018
Expires: September 26, 2018
Decentralized Service Architecture for OAuth2.0
draft-hardjono-oauth-decentralized-02
Abstract
This document proposes an alternative service architecture for user-
centric control of the sharing of resources following the UMA model,
such as personal data, using the decentralized peer-to-peer computing
paradigm. The term 'control' is used here to denote the full
capacity of the user to freely select (i) the entities with whom to
share resources (e.g. data), and (ii) the entities which provide
services implementing user-controlled resource sharing. The peer-to-
peer service architecture uses a set of computing nodes called
OAuth2.0 Nodes (ON) that are part of a peer-to-peer network as the
basis for the decentralized service architecture.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 26, 2018.
Hardjono Expires September 26, 2018 [Page 1]
Internet-Draft Decentralized OAuth March 2018
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The OAuth2.0 Node . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Node Definition . . . . . . . . . . . . . . . . . . . . . 5
2.2. OAuth2.0 Services . . . . . . . . . . . . . . . . . . . . 7
2.3. ON Local Functions . . . . . . . . . . . . . . . . . . . 8
2.4. Other OAuth2.0 Terminology . . . . . . . . . . . . . . . 8
2.5. ON Public Keys . . . . . . . . . . . . . . . . . . . . . 9
2.6. Transaction Model . . . . . . . . . . . . . . . . . . . . 10
2.7. Exclusivity of UMA-Services . . . . . . . . . . . . . . . 11
2.8. Identifying UMA-Services . . . . . . . . . . . . . . . . 11
3. Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Contracts definition . . . . . . . . . . . . . . . . . . 12
3.2. Smart Contracts . . . . . . . . . . . . . . . . . . . . . 12
3.3. Types of Contracts . . . . . . . . . . . . . . . . . . . 13
3.4. ON node acquisition contracts: parameters . . . . . . . . 13
3.5. Resource sharing contracts: parameters . . . . . . . . . 14
4. Contracts Server in the UMA Context . . . . . . . . . . . . . 15
4.1. The Contracts server . . . . . . . . . . . . . . . . . . 16
4.2. Contracts Sub-Flow in the UMA Flow . . . . . . . . . . . 16
4.3. Revoking a resource sharing license . . . . . . . . . . . 17
4.4. Cascading revocations . . . . . . . . . . . . . . . . . . 18
5. Design Issues and Challenges . . . . . . . . . . . . . . . . 18
5.1. Instrumentation of nodes . . . . . . . . . . . . . . . . 18
5.2. Protection of private keys . . . . . . . . . . . . . . . 19
5.3. Throughput of smart contracts agreement . . . . . . . . . 19
5.4. Moving ON nodes across providers . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
Hardjono Expires September 26, 2018 [Page 2]
Internet-Draft Decentralized OAuth March 2018
10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
This document proposes an alternative decentralized service
architecture for user-centric control of the sharing of resources,
such as personal data, using the decentralized peer-to-peer computing
paradigm. More specifically, we propose a decentralized service
architecture based on the User Managed Access grant of OAuth
(referred to as UMA2.0). As data becomes increasingly crucial for
the operations of the data-driven society, the issue of privacy and
control over data will become increasingly important for individuals
and organizations. The current services paradigm employed today
originated from the early years of the development of the Internet
ISP model and as such is largely outdated.
One key important contribution of UMA is the recognition that in the
real-world deployments of services there are entities (e.g. service
provider and operators) which are not specified by the OAuth2.0
framework and which therefore may not visible to the resource owner.
For example, UMA recognizes that the client is typically a web
application that is owned and operated by a third-party service with
whom the resource owner may not have a direct relationship. As such,
in the basic OAuth2.0 definition the resources (such as data) flowing
from the resource server to the requesting party passes through the
client, even though the resource owner may not have authorized the
client-operator (a service provider) to have access to this data.
In this document the term 'control' is used to denote the full
capacity of the user to freely select (i) the entities with whom to
share resources (e.g. data), and (ii) the entities which provide
services implementing resource sharing.
We propose the use of a peer-to-peer (P2P) service architecture to
provide decentralization of services and portability of data, using
digital smart contracts as the legal mechanism to bind service
providers:
o Decentralization of services: At the infrastructure level,
decentralization of service means enabling a user to select the
service providers that will provide the user with full control
over managing access to the user's resources, in particular for
user-owned data.
o Portability of data and services: At the data level,
decentralization of control means the freedom for the user to
Hardjono Expires September 26, 2018 [Page 3]
Internet-Draft Decentralized OAuth March 2018
switch service providers at any moment in time and with ease. As
such, portability of data and interoperability of services across
providers is crucial to allow the user to retain independence from
any specific service provider.
o Automated service-provisioning through contracts: Decentralization
of service and portability of data can be enabled by automation in
the provisioning and de-provisioning of services, based on an
automated contracts model. Such an automated model must be
legally enforceable and must enable users to switch providers
rapidly without degradation in control, privacy or sharing levels.
The recent development of blockchain systems and distributed leger
technologies offers the possibility of parties transacting on a
common ledger (public or private), with reduced costs through
increased automation and with reduced friction through the increased
visibility on the part of the transacting entities. Core to this
notion of 'business on the blockchain' is the concept of the smart
contract as being the digital equivalent of the paper contract.
The programmability aspect of some blockchain systems offers the
possibility of using code on the blockchain to provision, activate
and retire services in an automated fashion.
We propose the use of smart contract technology as a means to enable
users to legally obtain and control a compute-unit which contain
services compliant to well-defined standard specifications. These
compute-units could be made available by infrastructure service
providers in the form of operating-system-level virtualization images
(i.e. containerization), or other forms of hosted technologies. In
this case our compute-unit would contain a set of standard UMA2.0
services. We refer to this compute-unit as the OAuth2.0 Node (ON).
We refer to the infrastructure service providers who furnish an ON
node as the node-operator (or simply operator).
Each ON node has the capability to provide AS-services, RS-services
and Client-services following the UMA2.0 standard. Each node also
has the capability to provide authentication services for other nodes
and users, following the OpenID-Connect 1.0 model.
The peer-to-peer (P2P) model for the ON nodes enables users who
possess ON nodes to transact with each other as equal peers. For
example, an individual Bob as the requesting party may create an ON
node and use the client in that node to request access to resources
belonging to Alice. In her turn, Alice will use the authorization
server and resource server in her ON node to respond to Bob's
request.
Hardjono Expires September 26, 2018 [Page 4]
Internet-Draft Decentralized OAuth March 2018
Additionally, and more interestingly, Alice may stand-up a network of
ON nodes where each node may be dedicated to managing certain types
of resources belonging to Alice. This network of ON nodes may
perform inter-federation among themselves, allowing each ON node to
serve different requesting parties and clients at scale as suitable
to each transaction context and resource type.
A user seeking to acquire and control an ON node should not need to
be aware of how the node is implemented and instrumented by node
operators. The role of smart contracts here is to ensure that the
user obtains from the node operator the ON node as a compute-unit as
specified, and that the user has the control over the ON node and its
associated resources (user-level resources, and instrumentation or
configuration resources for that node).
With regards to smart contracts -- which is currently still an
evolving discipline -- one key requirement is the ability for the
contractual obligations stated in the smart contract to be legally
enforceable. Methods such as combining contract-code with legal-
prose within the smart contract offers a possible solution to this
question.
In the following we describe in more detail the functions of the
node. The reader is assumed to have familiarity with OAuth2.0
[OAuth2.0], OpenID-Connect Core [OIDCCore] and UMA 2.0 [UMA2.0].
2. The OAuth2.0 Node
This document proposes the use a peer-to-peer (P2P) network of nodes
as the basis for a decentralized service architecture for user-
centric management of data sharing and service provisioning.
2.1. Node Definition
Each node is referred to as an OAuth2.0 Node (ON), and a ON compute-
unit implements the following UMA-related services and other services
(Figure 1): Authorization Server, Resource Server, Confidential
Client, Policy Server, OpenID-Connect Provider, Proxy/Forwarder,
Blockchain Client and Contracts Server. These services come with the
ON node as a compute-unit regardless whether the owner of the node
makes use of (i.e. activates) these services.
An individual or organization obtains an ON unit from the node
operator by entering into a ON node acquisition contract with the
node operator. The acquisition contract makes the user the "owner"
of that ON unit for the duration of the contract.
We distinguish between the node operator and the node owner:
Hardjono Expires September 26, 2018 [Page 5]
Internet-Draft Decentralized OAuth March 2018
o Node Operator: The legal owner of the infrastructure system
implementing and instrumenting an ON node throughout its lifecyle.
o Node Owner: The legal owner of the ON unit (with its associated
UMA services, functions, APIs, and resources) acquired for a
duration of time under a contract with the node operator.
o UMA-services operator: The operator of the services running within
an ON node. Given that the node-operator as the infrastructure
provider has mechanical control over the ON node as a hosted
compute-unit (including processes running inside the node), for
simplicity we assume that the node-operator is the legal operator
of the UMA-services.
It is crucial to highlight here that as the infrastructure provider
of ON nodes, the node-operator is still considered as the UMA-
services operator (at the UMA level), even though the user (owner)
has full legal control over the ON unit. This is because the node
operator who hosts the ON node still has the technical means to
perform unauthorized access to resources flowing between ON nodes and
to resident resources (i.e. data at rest) within an ON node. For
example, when Bob employs a client within his ON node, the operator
who hosts Bob's ON node still has the technical capacity to view
resource traffic flowing through that client.
Emerging technologies (e.g. secure enclaves, homomorphic encryption,
secure multiparty computation) promise solutions to this possibly
`dishonest' node-operator problem. But until these technologies are
well-understood, tested, standardized and widely deployed, it will be
difficult if not impossible to prevent (or even detect) dishonest
node-operators.
Hardjono Expires September 26, 2018 [Page 6]
Internet-Draft Decentralized OAuth March 2018
+------------------------------------------------+
| |
| +----------------+ +----------------+ |
| | Authorization | | OpenID-Connect | |
| | Server (AS) | | Provider (OP) | |
| +----------------+ +----------------+ |
| |
| +----------------+ +----------------+ |
| | Confidential | | Resource | |
| | Client (CC) | | Server (RS) | |
| +----------------+ +----------------+ |
| |
| +----------------+ +----------------+ |
| | Policy | | Proxy/ | |
| | Server (PS) | | Forwarder (PF) | |
| +----------------+ +----------------+ |
| |
| +----------------------------------------+ |
| |
| +----------------+ +----------------+ |
| | Blockchain | | Contracts | |
| | Client (BC) | | Server (CS) | |
| +----------------+ +----------------+ |
| |
+------------------------------------------------+
Figure 1: OAuth2.0 Node (ON)
2.2. OAuth2.0 Services
The following are services that are implemented by an OAuth2.0 Node
(ON):
Confidential Client: The Confidential Client (CC) is client that
possesses capabilities to store secrets, such as cryptographic
keys and other confidential parameters.
Authorization Server: The Authorization Server (AS) is a server that
protects resources managed at a resource server on a resource
owner's behalf.
Resource Server: The Resource Server (RS) is a server that hosts
resources on a Resource Owner's behalf, registers resources for
protection at an Authorization Server, and is capable of accepting
and responding to requests for access to protected resources.
Hardjono Expires September 26, 2018 [Page 7]
Internet-Draft Decentralized OAuth March 2018
OpenID Provider: The OpenID Provider (OP) implements authentication
of the Requesting Party and the Client. See [OIDCCore].
Policy Server: The Policy Server (PS) implements the policy
administration point (PAP) and policy decision point (PDP) for the
Resource Owner, for each resource owned by the Resource Owner.
Proxy/Forwarder: The Proxy/Forwarder (PF) implements proxying to
another node, relying on that node's implementation of the same
function.
2.3. ON Local Functions
The following are services that are implemented by an OAuth2.0 Node
(ON) for its own operations, and therefore are not available to other
entities:
Blockchain Client: The Blockchain Client (BC) implements the client
role in a blockchain system.
Contracts Server: The Contracts Server (CS) implements the contracts
management and fulfilment for users and with other ON nodes.
2.4. Other OAuth2.0 Terminology
The following is a set of terminologies used in OAuth2.0 and in
UMA2.0:
Requesting Party: The Requesting Party (RqP) is a natural or legal
person that uses a client to seek access to a protected resource.
The requesting party may or may not be the same party as the
resource owner.
Resource Owner: The Resource Owner (RO) is an entity capable of
granting access to a protected resource. This is typically an
end-user (a natural person) but it can also be non-human entity
that is treated as a person for limited legal purposes (a legal
person), such as a corporation.
Resource: A digital resource available through an HTTP service.
Protected Resource: A resource to which a resource owner is able to
control access grants through an authorization server.
Scope: A bounded extent of access to a protected resource. Scopes
are associated with particular resources.
Hardjono Expires September 26, 2018 [Page 8]
Internet-Draft Decentralized OAuth March 2018
Policy Conditions: Access grant rules configured at an Authorization
Server that effect resource protection.
Claim: A statement of the value or values of one or more attributes
of an entity.
Permission: Authorized access to a particular resource with one or
more scopes. A resource server requests one or more permissions
on behalf of a client at an authorization server.
2.5. ON Public Keys
For each ON node which the node operator establishes under contract
with the node-owner, the operator creates a new public-key pair and
assignes it to that ON node. We refer to this as the ON unit public-
key pair. The operator refers to that ON node (e.g. on the
blockchain) using that public key. This public-key pair is unique
for each ON node created by the operator, and the operator maintains
the private key.
This ON unit public-key pair is different from the operator's public-
key pair as a service provider.
Once an ON node is operational and ownership has been transferred to
the node-ower (e.g. Alice), the owner must generate and assign a
public-key pair to each UMA-service they wish to activate in the ON
node. The owner must also generate and assign a public-key pairs for
the Blockchain Client (BC) and Contracts Server (CS) in that ON node.
Thus, for example, if Alice is using only the Authorization Server
(AS) and Resource Server (RS) within her ON node, she must generate
and assign two (2) public-key pairs, for her AS and the RS
respectively, plus the public-key pairs for the BC and CS. The node
operator must never be able to obtain the private half of the public
keys of the services running within an ON node. The mechanics to
generate and assign public-key pairs are outside the scope of the
current specification.
The following is a list of public-key pairs related to a given
running ON node:
o ON unit public key: This is the public-key pair associated with
the ON node as a compute unit operating on the infrastructure of
the node operator.
o UMA-services public keys: This is the public-key pair of the UMA-
service running within an ON node. When invoked or activated by
the node-owner, each UMA-service must be associated with a unique
Hardjono Expires September 26, 2018 [Page 9]
Internet-Draft Decentralized OAuth March 2018
public-key pair. The blockchain client (BC) and the Contracts
Server (CS) must always be operational inside an ON node and must
each be assigned a public-key pair.
o Node Operator public key: This is the public-key pair of the node
operator as a legal entity. This key pair is used by the node
operator for signing smart contracts.
o Owner public-key pair: This is the public-key pair of the owner
(i.e. Alice). This key pair is used by the owner for signing
smart contracts
2.6. Transaction Model
The transaction model follows closely that of the UMA grant of
OAuth2.0 (also referred to as UMA2.0). In summary, a Requesting
Party (Bob) is seeking access to resources belonging to the Resource
Owner (Alice) through a Resource Server that Alice controls.
The Requesting Party (Bob) selects an ON (e.g. Node #1) to be his
Client in the transaction, while the Resource Owner has already
activated an ON (e.g. Node #3) to be the Authorization Server that
protects the target resource located at the Resource Server (e.g.
Node #2).
In order for the Requesting Party (Bob) to access the desired
resources controlled by the Resource Owner (Alice), two types of
exchanges may occur as part of a transaction:
o Requesting Party and Client authorization: When the Requesting
Party uses the Client (Node #1) to request access to a resource at
the Resource Server (Node #2) the Client must obtain an access
token from Authorization Server (Node #3).
o Requesting Party authentication: In the process of the Client
(Node #1) obtaining an access token from the Authorization Server
(Node #4), the Client may be directed to the OpenID-Provider (Node
#5) for the Requesting Party and Client to be authenticated.
(Note that this is part of the claims-gathering flow of UMA).
The method for Requesting Party to obtain information regarding the
available resources at a given Resource Server is outside the scope
of this document. The reader is directed to the UMA2.0
specifications.
The method of node selection is outside the scope of this document
and will be the subject of future specifications.
Hardjono Expires September 26, 2018 [Page 10]
Internet-Draft Decentralized OAuth March 2018
2.7. Exclusivity of UMA-Services
For simplicity of design, we propose the exclusive ownership of all
UMA-services within an ON node.
That is, when a user (e.g. Alice) purchases a ON node offered by an
node operator, that ON node is exclusively owned by (and under the
full control of) Alice throughout the duration of the contract. The
node operator must not advertise otherwise, and other users and
entities are able to verify the ownership of a given ON node (i.e. as
belonging to Alice) by validating the relevant confirmed smart
contract transaction (pertaining to the ON node acquision by Alice
from the operator) on the blockchain.
2.8. Identifying UMA-Services
UMA-Services and their endpoints within a given ON node may be
identifed based on the combined public keys related to the UMA-
service and the ON unit. The cryptographic hash of the combined UMA-
service (e.g. AS-service) public key and the ON unit public key
produces a hash-value which can be used to look-up the UMA-service
uniquely on a directory or on a blockchain-based naming service.
For example, both Alice and Bob may stand-up two distinct ON nodes
hosted by the same node operator. Each user may run their own AS-
service from within their respective ON nodes. The combined use of
the AS service end-point (URI) and these two public keys offer a
mechanism to distinguish between Alice's AS from Bob's AS.
3. Contracts
Contracts form the basis for ON node acquisition (on the
infrastructure level) and for resource/data sharing (at the UMA
level). ON node acquisition occurs between a user (individual or
organization) and an infrastructure node-operator.
Resource sharing contracts at the UMA-level capture the licensing of
access right to resources belonging to the resource owner. In this
sense the current proposal follows the UMA licensing model
[UMA-Legal].
Contracts must contain legal prose that bind relevant parties and
must contain indicators for dispute resolution.
Hardjono Expires September 26, 2018 [Page 11]
Internet-Draft Decentralized OAuth March 2018
3.1. Contracts definition
Contracts are legally binding agreements expressed in digital format
that clearly calls out the actors involved in a transaction, the
resources (i.e. data) being shared, legal prose (or pointers to legal
prose), methods for dispute resolution, and other legal aspects of
the transaction.
At the infrastructure level, the intent here is to support users
(individuals or organizations) to acquire ON node compute-units from
an infrastructure node operator in an automated or semi-automated
fashion, based on standardized templates of contracts.
Similarly, on the UMA level the intent is to support users
(individuals or organizations) to acquire licenses for resources in
an automated or semi-automated fashion.
For example, when Bob seeks to access resources belonging to Alice,
Bob's node operator (e.g. BNO Corp) and Alice's node operator (e.g.
ANO Corp) are involved in the transaction.
This is because when resources (e.g. data) are accessed by Bob and
flows from Alice's RS to Bob's Client, the node-operator of Bob's
Client (namely BNO Corp) may be able to obtain unauthorized access to
those resource. The contract must protect against this possible
unauthorized access.
3.2. Smart Contracts
A smart contract is a set of promises, specified in digital form,
including protocols within which the parties perform on these
promises. A smart contract should have the following features [NRF]:
o Digital form: it is in computer form - code, data and running
programs.
o Embedded: contractual clauses (or equivalent functional outcomes)
are embedded as computer code in software.
o Performance mediated by technological means: the release of
payments and other actions are enabled by technology and rules-
based operations.
o Irrevocable: once initiated, the outcomes for which a smart
contract is encoded to perform cannot typically be stopped (unless
an outcome depends on an unmet condition).
Hardjono Expires September 26, 2018 [Page 12]
Internet-Draft Decentralized OAuth March 2018
Contracts are digitally signed by the relevant parties and may be
recorded to a blockchain system or distributed ledger system. A
smart contract containing code and legal prose may be used to
automate the service agreement process.
For ON nodes, the smart contract defining the ON node acquisition
agreement must also specify the post-termination actions to be
performed by the node-operator on the user's ON node. This agreement
clause must define the transferal mechanism for resources and
services within the user's ON node. For example, the objects and
relevant assets (e.g. data; keys; tokens; etc.) could be packaged and
off-loaded to a location designated by the user in the smart
contract, such as another node or offline storage.
3.3. Types of Contracts
We propose distinguishing two (2) types of contracts:
o ON node acquisition contract: A ON node acquisition contract
denotes the acquisition of specific ON node as a compute-unit by a
user (individual or organization) from a given infrastructure node
operator. ON node acquisition contracts are typically bilateral
between a user and a node-operator.
o Resource sharing contract: A resource sharing contract denotes the
granting of license by a Resource Owner (to data or resources) to
a Requesting Party using the services rendered by infrastructure
node operator. See [UMA-Legal].
Parties that transact at the UMA-level through a resource sharing
contract must verify that (a) the counterparty posseses valid
contracts with their operators, and (b) that the operator contract
prohibits the operator from performing unathorized access to the
shared resources at the UMA-level.
3.4. ON node acquisition contracts: parameters
The following are some parameters needed within ON node acquisition
contracts:
o Type of contract ('ON node acquisition')
o Identifier of the user (individual or organization)
o Public key of the user
o Identifier of the ON node operator
Hardjono Expires September 26, 2018 [Page 13]
Internet-Draft Decentralized OAuth March 2018
o Public key of the ON node operator
o Version of ON node (i.e. container/image) and hash
o ON unit public-key
o ON unit identifier (e.g. URI)
o Exclusivity
o Duration of service
o End-of-contract actions
o Service fees and payment mechanism (optional)
o Dispute resolution method
o Legal prose
o Code (for smart contract embodiment)
o Timestamp
o Archive location of this contract (optional)
o Contract template identifier and author (optional)
o Target blockchain (for smart contract embodiment)
o Signature of User (individual or organization)
o Signature of node-operator
3.5. Resource sharing contracts: parameters
The following are some parameters needed within a resources sharing
contract based on the usage of ON nodes. Note that this contract
involves only the following UMA-entities: Requesting Party, Client,
Client node-operator, Resource Owner, Resource Server, Resource-
Server node operator, Authorization Server, Authorization-Server node
operator. Other flows and contracts will be addressed in future
documents.
o Type of contract ('resource sharing')
o UMA-services involved (identifier and public-key): RqP, Client,
AS, RS, RO
Hardjono Expires September 26, 2018 [Page 14]
Internet-Draft Decentralized OAuth March 2018
o Hash and pointer to the node acquisition contract between the
Client-owner and their node-operator.
o Hash and pointer to the node acquisition contract between the RO-
entity and the node-operator running the ON unit contaning their
Resource Server.
o Hash and pointer to the node acquisition contract between the AS-
owner and the node-operator running the ON unit contaning their
Authorization Server.
o Duration of data sharing contract
o End-of-contract actions
o Service fees and payment mechanism (optional)
o Dispute resolution method
o Legal Prose
* Data sharing license
o Code (for smart contract embodiment)
o Timestamp
o Archive location of this contract (optional)
o Contract template identifier and author (optional)
o Target blockchain (for smart contract embodiment)
o Signature of Requesting Party
o Signature of Resource Owner data
4. Contracts Server in the UMA Context
Contracts form the basis for ON node acquisition (on the
infrastructure level) and for resource/data sharing (at the UMA
level). ON node acquisition occurs between a user (individual or
organization) and an infrastructure node-operator.
Resource sharing contracts at the UMA-level capture the licensing of
access right to resources belonging to the resource owner. In this
sense the current proposal follows the UMA licensing model
[UMA-Legal].
Hardjono Expires September 26, 2018 [Page 15]
Internet-Draft Decentralized OAuth March 2018
Contracts must contain legal prose that bind relevant parties and
must contain indicators for dispute resolution.
4.1. The Contracts server
The Contract Server (CS) is a new functional capability introduced
into this architecture that did not previously exist in the OAuth2.0,
OIDC1.0 or UMA2.0 designs.
The contracts server is present at an ON node regardless of which
types of UMA-services are activated by the user (node owner). A
contracts server in an ON node only serves that node (i.e. it serves
the UMA-services active in that ON node). A contracts server cannot
be used by services outside its ON node.
Some of the core tasks of the contracts server on a node are as
follows:
o Locate and validate templates of standard contracts
o Interact with peer contracts server at other nodes (data sharing
contracts)
o Validate incoming contracts against standard template contracts
o Validate signatures on incoming contracts
o Sign contracts using the relevant private keys
o Record signed contract to blockchain (using Blockchain Client)
o Locate and validate executable-code related to a smart-contract.
Similar to endpoints in the UMA-services within an ON node, the
contracts server exposes a number of endpoints relevant to completing
contracts agreement (e.g. for resource sharing contracts).
4.2. Contracts Sub-Flow in the UMA Flow
There are several possible uses of the contracts server in the
context of the UMA flows.
For requesting access to protected resources (at the UMA level), the
role of the contracts server is to record the signed agreement
between the Requesting Party, Client and the Resource Owner prior to
the Authorization Server issuing an RPT token (Requesting Party
Token) to the Requesting Party.
Hardjono Expires September 26, 2018 [Page 16]
Internet-Draft Decentralized OAuth March 2018
That is, the contracts server injects a sub-flow within the UMA
resource access flow.
More specifically, when the Requesting Party (Bob) uses a Client (in
Node #1 owned by Carol) to request access to Alice's resources at the
Resource Server (in Node #2 owned by Alice), the contracts server
belonging to Alice (in Node 2) must perform the following:
a. It must prompt the Requesting Party (Bob), namely a human person,
to sign the license agreement pertaining to the protected
resources belonging to Alice.
b. It must search for (on the blockchain) the valid ON node
acquisition contract between Carol and her node operator. This
indicates that Carol is truly the legal owner of the ON unit
(Node #1) running the Client.
c. It must engage the contracts server in Node #1 belonging to Carol
to sign the license agreement pertaining to the protected
resources belonging to Alice. (Note that Alice's license may
already be defined a smart contract sitting on her chosen
blockchain system). Both contracts server must record the signed
agreement to the same blockchain system, with Alice's contracts
server have first choice in the selection of the blockchain
system..
d. If the ON node acquisition contract for Carol's ON unit (Node #1)
did not provide legal coverage against her operator eavesdropping
(i.e. stealing data or resources), then Alice's contracts server
must engage Carol's node-operator to sign a license agreement
suitable for the operator.
Only after the respective contracts servers have completed the
license agreement and have these recorded on the blockchain (or have
it executed on the blockchain), should the RPT token issuance flow
continue.
Note that in the UMA context the resource sharing license may have a
long duration, which means that the above license signing sub-flow
need not be repeated if the license contracts are still valid and
unrevoked.
4.3. Revoking a resource sharing license
Once of the key value proposition of UMA is the revocation of
licenses, which is in-line with a number of requirements in the GDPR.
Hardjono Expires September 26, 2018 [Page 17]
Internet-Draft Decentralized OAuth March 2018
In the case of license revocation, Alice instructs her contracts
server to issue a license-revocation transaction (LRT) to the same
blockchain where the original license was created or executed.
The license-revocation transaction must point to (i.e. include the
hash) of the original license. .
4.4. Cascading revocations
It is relevant to note that when Alice revokes access to Bob (the
Requesting Party), Alice has the option to also revoke both the
license contract with Carol (the owner of the Node #1 running the
Client used by Bob) and the license contract with the node-operator
of Carol's ON node (operator of Node #1).
In this scenario, Alice's contracts server must issue several
license-revocation transactions on the blockchain to terminate these
license contracts.
However, Alice has the option to retain the (long term) license
contract with Carol (owner of the Client in Node #1) and the operator
of Node #1. Alice may do this, for example, in anticipation of other
future Requesting Parties using the same Client owned by Carol (e.g.
the Client is an extremely popular social media client).
5. Design Issues and Challenges
There are a number of design issues and challenges with the
decentralized service architecture, arising from the need to achieve
the goals of (i) decentralization of services, (ii) portability of
data and services, and (iii) automated service-provisioning through
contracts. Some of these issues are discussed below (not an
exhaustive list).
5.1. Instrumentation of nodes
One key question pertains to the instrumentation of ON nodes. A user
(potential owner of an ON node) should be able to acquire an ON node
with relative ease through the proper instrumentation tools that
common today. A node acquisition contract should specify the tools
and services available to the user to instrument and control their ON
nodes.
Alternate models maybe explored, including the use of a manageability
node that represents the user's launch-pad and control point for
their entire network of ON nodes.
Hardjono Expires September 26, 2018 [Page 18]
Internet-Draft Decentralized OAuth March 2018
5.2. Protection of private keys
An important aspect of systems employing public-key cryptography is
the protection of the private-keys. Thus, Alice as the owner of a
given ON node must protect the keys associated with all the UMA-
services (plus the BC and CS) in her ON node.
5.3. Throughput of smart contracts agreement
Speed of processing smart contracts (e.g. licnese agreement between
to CS servers) is an important aspect because the main UMA flow may
be blocking or waiting for the contracts sub-flow to complete.
5.4. Moving ON nodes across providers
In order to achieve true independence from any given service
provider, the owner of a given ON must be able to `move' his or her
ON node (together with all the internal relevant resources and
configurations) to a new ON node at a new node-operator.
Several issues remain open, ranging from a standardized packaging
format to the need to re-generate some identifiers for the UMA-
services (i.e. new ON node is assigned a new ON unit public key by
the new node-operator).
Her, there is a role for the Proxy/Forwarder Service in an ON node as
way to redirect requests to the new ON node while the old ON node is
being shut-down.
6. IANA Considerations
TBD.
7. Security Considerations
This document pertains to a peer-to-peer infrastructure for resource
sharing based on the UMA model using digital contractsand licenses.
As such, there are numerous security aspect of deployments that need
to be considered.
Aside from known traditional security challenges (e.g. channel
binding to keys), there are new security questions that arise due to
the proposed use of a peer-to-peer network of nodes as the basis for
a decentralized service architecture. Some interesting issues
include:
Proof of correct execution: One of the security challenges involves
obtaining evidence that a node has not deviated from the agreed
Hardjono Expires September 26, 2018 [Page 19]
Internet-Draft Decentralized OAuth March 2018
behavior (as defined in a contract) and has not created side-
effects (intentional or unintentional).
Proof of data erasure: For a node that act as a resource server
holding data belonging to the resource owner, there is a need to
provide some mechanism that provides sufficient evidence that data
erasure from the node has occurred. Such mechanisms would be
useful to parties external to the node, but clearly does not
address data copying (data theft) by the node.
Correct service definition: When contracts specify certain agreed
services (both in node acquisition contracts and resource sharing
contracts), there is the question of the correct service semantics
being captured in the specified contract, both in the legal prose
and within executable code.
8. Privacy Considerations
This document follows closely the UMA grant of OAuth2.0. The
authorization server at an ON comes to be in possession of data/
resource information that may reveal information about the resource
owner, which the authorization server's trust relationship with the
resource server is assumed to accommodate.
The Client and Requesting Party are assumed to be a less-trusted. In
fact, these entities are considered entirely untrustworthy until the
data sharing contract has been established with the Resource Owner.
Following UMA grant of OAuth2.0, the primary privacy duty of the
current decentralized design is to the Resource Owner. However,
privacy considerations affect the Requesting Party as well. This can
be seen in the issuance of an UMA related tokens, which represents
the approval of a Requesting Party for a Client (ON) to engage with
an Authorization Server to perform tasks needed for obtaining
authorization, possibly including pushing claim tokens
9. Acknowledgements
We thank the following for feedback and inputs on technical and legal
aspects (alphabetical last name): Justin Anderson (MIT), James Hazard
(IACCM), Cameron Kerry (MIT), Eve Maler (ForgeRock), Alex Pentland
(MIT), Tim Reiniger (Future Law).
10. References
Hardjono Expires September 26, 2018 [Page 20]
Internet-Draft Decentralized OAuth March 2018
10.1. Normative References
[JSON] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", March 2014,
<https://tools.ietf.org/html/rfc7159>.
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
May 2015, <http://tools.ietf.org/html/rfc7516>.
[JWK] Jones, M., "JSON Web Key (JWK)", May 2015,
<http://tools.ietf.org/html/rfc7517>.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", May 2015,
<http://tools.ietf.org/html/rfc7515>.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", May 2015, <http://tools.ietf.org/html/rfc7519>.
[OAuth2.0]
Hardt, D., "The OAuth 2.0 Authorization Framework",
October 2012, <http://tools.ietf.org/html/rfc6749>.
[OIDCCore]
Sakimura, N., "OpenID Connect Core 1.0 incorporating
errata set 1", November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[UMA1.0] Hardjono, T., Maler, E., Machulak, M., and D. Catalano,
"User-Managed Access (UMA) Profile of OAuth 2.0", December
2015, <https://docs.kantarainitiative.org/uma/
rec-uma-core.html>.
[UMA2.0] Maler, E., Machulak, M., and J. Richer, "User-Managed
Access (UMA) 2.0", January 2017,
<https://github.com/KantaraInitiative/wg-uma>.
10.2. Informative References
[Bitcoin] Nakamoto, S., "Bitcoin: a Peer to Peer Electronic Cash
system", 2008, <https://bitcoin.org/bitcoin.pdf>.
Hardjono Expires September 26, 2018 [Page 21]
Internet-Draft Decentralized OAuth March 2018
[BSC-DG] Hardjono, T. and E,. Maler, "Kantara Blockchain and Smart
Contract Discussion Group Report", January 2018,
<https://kantarainitiative.org/kantara-initiative-
releases-first-blockchain-report-addressing-privacy-
protection-and-personal-data/>.
[NRF] Norton Rose Fulbright, "Can Smart Contracts be Legally
Binding Contracts", January 2018,
<http://www.nortonrosefulbright.com/knowledge/
publications/144559/
can-smart-contracts-be-legally-binding-contracts>.
[OIX] "OpenID Exchange", <http://www.openidentityexchange.org>.
[OMS] Hardjono, T., Deegan, P., and J. Clippinger, "On the
Design of Trustworthy Compute Frameworks for Self-
organizing Digital Institutions (HCI 2014)", June 2014,
<http://link.springer.com/
chapter/10.1007/978-3-319-07632-4_33>.
[OpenPDS] de Montjoye, Y., Wang, S., and A. Pentland, "openPDS: On
the Trusted Use of Large-Scale Personal Data (IEEE Data
Engineering)", December 2012,
<http://sites.computer.org/debull/A12dec/p5.pdf>.
[UMA-Legal]
Reiniger, T., "A Proposed Licensing Model for User Managed
Access", January 2018,
<https://kantarainitiative.org/confluence/display/uma/
UMA+Legal>.
Author's Address
Thomas Hardjono
MIT
Email: hardjono@mit.edu
Hardjono Expires September 26, 2018 [Page 22]
