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, . [JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", May 2015, . [JWK] Jones, M., "JSON Web Key (JWK)", May 2015, . [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", May 2015, . [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", May 2015, . [OAuth2.0] Hardt, D., "The OAuth 2.0 Authorization Framework", October 2012, . [OIDCCore] Sakimura, N., "OpenID Connect Core 1.0 incorporating errata set 1", November 2014, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [UMA1.0] Hardjono, T., Maler, E., Machulak, M., and D. Catalano, "User-Managed Access (UMA) Profile of OAuth 2.0", December 2015, . [UMA2.0] Maler, E., Machulak, M., and J. Richer, "User-Managed Access (UMA) 2.0", January 2017, . 10.2. Informative References [Bitcoin] Nakamoto, S., "Bitcoin: a Peer to Peer Electronic Cash system", 2008, . 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, . [NRF] Norton Rose Fulbright, "Can Smart Contracts be Legally Binding Contracts", January 2018, . [OIX] "OpenID Exchange", . [OMS] Hardjono, T., Deegan, P., and J. Clippinger, "On the Design of Trustworthy Compute Frameworks for Self- organizing Digital Institutions (HCI 2014)", June 2014, . [OpenPDS] de Montjoye, Y., Wang, S., and A. Pentland, "openPDS: On the Trusted Use of Large-Scale Personal Data (IEEE Data Engineering)", December 2012, . [UMA-Legal] Reiniger, T., "A Proposed Licensing Model for User Managed Access", January 2018, . Author's Address Thomas Hardjono MIT Email: hardjono@mit.edu Hardjono Expires September 26, 2018 [Page 22]