idnits 2.17.1 draft-hardjono-oauth-decentralized-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 25, 2018) is 2222 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'JSON' is defined on line 932, but no explicit reference was found in the text == Unused Reference: 'JWE' is defined on line 936, but no explicit reference was found in the text == Unused Reference: 'JWK' is defined on line 939, but no explicit reference was found in the text == Unused Reference: 'JWS' is defined on line 942, but no explicit reference was found in the text == Unused Reference: 'JWT' is defined on line 946, but no explicit reference was found in the text == Unused Reference: 'Bitcoin' is defined on line 974, but no explicit reference was found in the text == Unused Reference: 'BSC-DG' is defined on line 977, but no explicit reference was found in the text == Unused Reference: 'OIX' is defined on line 989, but no explicit reference was found in the text == Unused Reference: 'OMS' is defined on line 991, but no explicit reference was found in the text == Unused Reference: 'OpenPDS' is defined on line 997, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7159 (ref. 'JSON') (Obsoleted by RFC 8259) Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group T. Hardjono 3 Internet-Draft MIT 4 Intended status: Informational March 25, 2018 5 Expires: September 26, 2018 7 Decentralized Service Architecture for OAuth2.0 8 draft-hardjono-oauth-decentralized-02 10 Abstract 12 This document proposes an alternative service architecture for user- 13 centric control of the sharing of resources following the UMA model, 14 such as personal data, using the decentralized peer-to-peer computing 15 paradigm. The term 'control' is used here to denote the full 16 capacity of the user to freely select (i) the entities with whom to 17 share resources (e.g. data), and (ii) the entities which provide 18 services implementing user-controlled resource sharing. The peer-to- 19 peer service architecture uses a set of computing nodes called 20 OAuth2.0 Nodes (ON) that are part of a peer-to-peer network as the 21 basis for the decentralized service architecture. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 26, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. The OAuth2.0 Node . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1. Node Definition . . . . . . . . . . . . . . . . . . . . . 5 66 2.2. OAuth2.0 Services . . . . . . . . . . . . . . . . . . . . 7 67 2.3. ON Local Functions . . . . . . . . . . . . . . . . . . . 8 68 2.4. Other OAuth2.0 Terminology . . . . . . . . . . . . . . . 8 69 2.5. ON Public Keys . . . . . . . . . . . . . . . . . . . . . 9 70 2.6. Transaction Model . . . . . . . . . . . . . . . . . . . . 10 71 2.7. Exclusivity of UMA-Services . . . . . . . . . . . . . . . 11 72 2.8. Identifying UMA-Services . . . . . . . . . . . . . . . . 11 73 3. Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 3.1. Contracts definition . . . . . . . . . . . . . . . . . . 12 75 3.2. Smart Contracts . . . . . . . . . . . . . . . . . . . . . 12 76 3.3. Types of Contracts . . . . . . . . . . . . . . . . . . . 13 77 3.4. ON node acquisition contracts: parameters . . . . . . . . 13 78 3.5. Resource sharing contracts: parameters . . . . . . . . . 14 79 4. Contracts Server in the UMA Context . . . . . . . . . . . . . 15 80 4.1. The Contracts server . . . . . . . . . . . . . . . . . . 16 81 4.2. Contracts Sub-Flow in the UMA Flow . . . . . . . . . . . 16 82 4.3. Revoking a resource sharing license . . . . . . . . . . . 17 83 4.4. Cascading revocations . . . . . . . . . . . . . . . . . . 18 84 5. Design Issues and Challenges . . . . . . . . . . . . . . . . 18 85 5.1. Instrumentation of nodes . . . . . . . . . . . . . . . . 18 86 5.2. Protection of private keys . . . . . . . . . . . . . . . 19 87 5.3. Throughput of smart contracts agreement . . . . . . . . . 19 88 5.4. Moving ON nodes across providers . . . . . . . . . . . . 19 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 91 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 92 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 95 10.2. Informative References . . . . . . . . . . . . . . . . . 21 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 98 1. Introduction 100 This document proposes an alternative decentralized service 101 architecture for user-centric control of the sharing of resources, 102 such as personal data, using the decentralized peer-to-peer computing 103 paradigm. More specifically, we propose a decentralized service 104 architecture based on the User Managed Access grant of OAuth 105 (referred to as UMA2.0). As data becomes increasingly crucial for 106 the operations of the data-driven society, the issue of privacy and 107 control over data will become increasingly important for individuals 108 and organizations. The current services paradigm employed today 109 originated from the early years of the development of the Internet 110 ISP model and as such is largely outdated. 112 One key important contribution of UMA is the recognition that in the 113 real-world deployments of services there are entities (e.g. service 114 provider and operators) which are not specified by the OAuth2.0 115 framework and which therefore may not visible to the resource owner. 116 For example, UMA recognizes that the client is typically a web 117 application that is owned and operated by a third-party service with 118 whom the resource owner may not have a direct relationship. As such, 119 in the basic OAuth2.0 definition the resources (such as data) flowing 120 from the resource server to the requesting party passes through the 121 client, even though the resource owner may not have authorized the 122 client-operator (a service provider) to have access to this data. 124 In this document the term 'control' is used to denote the full 125 capacity of the user to freely select (i) the entities with whom to 126 share resources (e.g. data), and (ii) the entities which provide 127 services implementing resource sharing. 129 We propose the use of a peer-to-peer (P2P) service architecture to 130 provide decentralization of services and portability of data, using 131 digital smart contracts as the legal mechanism to bind service 132 providers: 134 o Decentralization of services: At the infrastructure level, 135 decentralization of service means enabling a user to select the 136 service providers that will provide the user with full control 137 over managing access to the user's resources, in particular for 138 user-owned data. 140 o Portability of data and services: At the data level, 141 decentralization of control means the freedom for the user to 142 switch service providers at any moment in time and with ease. As 143 such, portability of data and interoperability of services across 144 providers is crucial to allow the user to retain independence from 145 any specific service provider. 147 o Automated service-provisioning through contracts: Decentralization 148 of service and portability of data can be enabled by automation in 149 the provisioning and de-provisioning of services, based on an 150 automated contracts model. Such an automated model must be 151 legally enforceable and must enable users to switch providers 152 rapidly without degradation in control, privacy or sharing levels. 154 The recent development of blockchain systems and distributed leger 155 technologies offers the possibility of parties transacting on a 156 common ledger (public or private), with reduced costs through 157 increased automation and with reduced friction through the increased 158 visibility on the part of the transacting entities. Core to this 159 notion of 'business on the blockchain' is the concept of the smart 160 contract as being the digital equivalent of the paper contract. 162 The programmability aspect of some blockchain systems offers the 163 possibility of using code on the blockchain to provision, activate 164 and retire services in an automated fashion. 166 We propose the use of smart contract technology as a means to enable 167 users to legally obtain and control a compute-unit which contain 168 services compliant to well-defined standard specifications. These 169 compute-units could be made available by infrastructure service 170 providers in the form of operating-system-level virtualization images 171 (i.e. containerization), or other forms of hosted technologies. In 172 this case our compute-unit would contain a set of standard UMA2.0 173 services. We refer to this compute-unit as the OAuth2.0 Node (ON). 174 We refer to the infrastructure service providers who furnish an ON 175 node as the node-operator (or simply operator). 177 Each ON node has the capability to provide AS-services, RS-services 178 and Client-services following the UMA2.0 standard. Each node also 179 has the capability to provide authentication services for other nodes 180 and users, following the OpenID-Connect 1.0 model. 182 The peer-to-peer (P2P) model for the ON nodes enables users who 183 possess ON nodes to transact with each other as equal peers. For 184 example, an individual Bob as the requesting party may create an ON 185 node and use the client in that node to request access to resources 186 belonging to Alice. In her turn, Alice will use the authorization 187 server and resource server in her ON node to respond to Bob's 188 request. 190 Additionally, and more interestingly, Alice may stand-up a network of 191 ON nodes where each node may be dedicated to managing certain types 192 of resources belonging to Alice. This network of ON nodes may 193 perform inter-federation among themselves, allowing each ON node to 194 serve different requesting parties and clients at scale as suitable 195 to each transaction context and resource type. 197 A user seeking to acquire and control an ON node should not need to 198 be aware of how the node is implemented and instrumented by node 199 operators. The role of smart contracts here is to ensure that the 200 user obtains from the node operator the ON node as a compute-unit as 201 specified, and that the user has the control over the ON node and its 202 associated resources (user-level resources, and instrumentation or 203 configuration resources for that node). 205 With regards to smart contracts -- which is currently still an 206 evolving discipline -- one key requirement is the ability for the 207 contractual obligations stated in the smart contract to be legally 208 enforceable. Methods such as combining contract-code with legal- 209 prose within the smart contract offers a possible solution to this 210 question. 212 In the following we describe in more detail the functions of the 213 node. The reader is assumed to have familiarity with OAuth2.0 214 [OAuth2.0], OpenID-Connect Core [OIDCCore] and UMA 2.0 [UMA2.0]. 216 2. The OAuth2.0 Node 218 This document proposes the use a peer-to-peer (P2P) network of nodes 219 as the basis for a decentralized service architecture for user- 220 centric management of data sharing and service provisioning. 222 2.1. Node Definition 224 Each node is referred to as an OAuth2.0 Node (ON), and a ON compute- 225 unit implements the following UMA-related services and other services 226 (Figure 1): Authorization Server, Resource Server, Confidential 227 Client, Policy Server, OpenID-Connect Provider, Proxy/Forwarder, 228 Blockchain Client and Contracts Server. These services come with the 229 ON node as a compute-unit regardless whether the owner of the node 230 makes use of (i.e. activates) these services. 232 An individual or organization obtains an ON unit from the node 233 operator by entering into a ON node acquisition contract with the 234 node operator. The acquisition contract makes the user the "owner" 235 of that ON unit for the duration of the contract. 237 We distinguish between the node operator and the node owner: 239 o Node Operator: The legal owner of the infrastructure system 240 implementing and instrumenting an ON node throughout its lifecyle. 242 o Node Owner: The legal owner of the ON unit (with its associated 243 UMA services, functions, APIs, and resources) acquired for a 244 duration of time under a contract with the node operator. 246 o UMA-services operator: The operator of the services running within 247 an ON node. Given that the node-operator as the infrastructure 248 provider has mechanical control over the ON node as a hosted 249 compute-unit (including processes running inside the node), for 250 simplicity we assume that the node-operator is the legal operator 251 of the UMA-services. 253 It is crucial to highlight here that as the infrastructure provider 254 of ON nodes, the node-operator is still considered as the UMA- 255 services operator (at the UMA level), even though the user (owner) 256 has full legal control over the ON unit. This is because the node 257 operator who hosts the ON node still has the technical means to 258 perform unauthorized access to resources flowing between ON nodes and 259 to resident resources (i.e. data at rest) within an ON node. For 260 example, when Bob employs a client within his ON node, the operator 261 who hosts Bob's ON node still has the technical capacity to view 262 resource traffic flowing through that client. 264 Emerging technologies (e.g. secure enclaves, homomorphic encryption, 265 secure multiparty computation) promise solutions to this possibly 266 `dishonest' node-operator problem. But until these technologies are 267 well-understood, tested, standardized and widely deployed, it will be 268 difficult if not impossible to prevent (or even detect) dishonest 269 node-operators. 271 +------------------------------------------------+ 272 | | 273 | +----------------+ +----------------+ | 274 | | Authorization | | OpenID-Connect | | 275 | | Server (AS) | | Provider (OP) | | 276 | +----------------+ +----------------+ | 277 | | 278 | +----------------+ +----------------+ | 279 | | Confidential | | Resource | | 280 | | Client (CC) | | Server (RS) | | 281 | +----------------+ +----------------+ | 282 | | 283 | +----------------+ +----------------+ | 284 | | Policy | | Proxy/ | | 285 | | Server (PS) | | Forwarder (PF) | | 286 | +----------------+ +----------------+ | 287 | | 288 | +----------------------------------------+ | 289 | | 290 | +----------------+ +----------------+ | 291 | | Blockchain | | Contracts | | 292 | | Client (BC) | | Server (CS) | | 293 | +----------------+ +----------------+ | 294 | | 295 +------------------------------------------------+ 297 Figure 1: OAuth2.0 Node (ON) 299 2.2. OAuth2.0 Services 301 The following are services that are implemented by an OAuth2.0 Node 302 (ON): 304 Confidential Client: The Confidential Client (CC) is client that 305 possesses capabilities to store secrets, such as cryptographic 306 keys and other confidential parameters. 308 Authorization Server: The Authorization Server (AS) is a server that 309 protects resources managed at a resource server on a resource 310 owner's behalf. 312 Resource Server: The Resource Server (RS) is a server that hosts 313 resources on a Resource Owner's behalf, registers resources for 314 protection at an Authorization Server, and is capable of accepting 315 and responding to requests for access to protected resources. 317 OpenID Provider: The OpenID Provider (OP) implements authentication 318 of the Requesting Party and the Client. See [OIDCCore]. 320 Policy Server: The Policy Server (PS) implements the policy 321 administration point (PAP) and policy decision point (PDP) for the 322 Resource Owner, for each resource owned by the Resource Owner. 324 Proxy/Forwarder: The Proxy/Forwarder (PF) implements proxying to 325 another node, relying on that node's implementation of the same 326 function. 328 2.3. ON Local Functions 330 The following are services that are implemented by an OAuth2.0 Node 331 (ON) for its own operations, and therefore are not available to other 332 entities: 334 Blockchain Client: The Blockchain Client (BC) implements the client 335 role in a blockchain system. 337 Contracts Server: The Contracts Server (CS) implements the contracts 338 management and fulfilment for users and with other ON nodes. 340 2.4. Other OAuth2.0 Terminology 342 The following is a set of terminologies used in OAuth2.0 and in 343 UMA2.0: 345 Requesting Party: The Requesting Party (RqP) is a natural or legal 346 person that uses a client to seek access to a protected resource. 347 The requesting party may or may not be the same party as the 348 resource owner. 350 Resource Owner: The Resource Owner (RO) is an entity capable of 351 granting access to a protected resource. This is typically an 352 end-user (a natural person) but it can also be non-human entity 353 that is treated as a person for limited legal purposes (a legal 354 person), such as a corporation. 356 Resource: A digital resource available through an HTTP service. 358 Protected Resource: A resource to which a resource owner is able to 359 control access grants through an authorization server. 361 Scope: A bounded extent of access to a protected resource. Scopes 362 are associated with particular resources. 364 Policy Conditions: Access grant rules configured at an Authorization 365 Server that effect resource protection. 367 Claim: A statement of the value or values of one or more attributes 368 of an entity. 370 Permission: Authorized access to a particular resource with one or 371 more scopes. A resource server requests one or more permissions 372 on behalf of a client at an authorization server. 374 2.5. ON Public Keys 376 For each ON node which the node operator establishes under contract 377 with the node-owner, the operator creates a new public-key pair and 378 assignes it to that ON node. We refer to this as the ON unit public- 379 key pair. The operator refers to that ON node (e.g. on the 380 blockchain) using that public key. This public-key pair is unique 381 for each ON node created by the operator, and the operator maintains 382 the private key. 384 This ON unit public-key pair is different from the operator's public- 385 key pair as a service provider. 387 Once an ON node is operational and ownership has been transferred to 388 the node-ower (e.g. Alice), the owner must generate and assign a 389 public-key pair to each UMA-service they wish to activate in the ON 390 node. The owner must also generate and assign a public-key pairs for 391 the Blockchain Client (BC) and Contracts Server (CS) in that ON node. 393 Thus, for example, if Alice is using only the Authorization Server 394 (AS) and Resource Server (RS) within her ON node, she must generate 395 and assign two (2) public-key pairs, for her AS and the RS 396 respectively, plus the public-key pairs for the BC and CS. The node 397 operator must never be able to obtain the private half of the public 398 keys of the services running within an ON node. The mechanics to 399 generate and assign public-key pairs are outside the scope of the 400 current specification. 402 The following is a list of public-key pairs related to a given 403 running ON node: 405 o ON unit public key: This is the public-key pair associated with 406 the ON node as a compute unit operating on the infrastructure of 407 the node operator. 409 o UMA-services public keys: This is the public-key pair of the UMA- 410 service running within an ON node. When invoked or activated by 411 the node-owner, each UMA-service must be associated with a unique 412 public-key pair. The blockchain client (BC) and the Contracts 413 Server (CS) must always be operational inside an ON node and must 414 each be assigned a public-key pair. 416 o Node Operator public key: This is the public-key pair of the node 417 operator as a legal entity. This key pair is used by the node 418 operator for signing smart contracts. 420 o Owner public-key pair: This is the public-key pair of the owner 421 (i.e. Alice). This key pair is used by the owner for signing 422 smart contracts 424 2.6. Transaction Model 426 The transaction model follows closely that of the UMA grant of 427 OAuth2.0 (also referred to as UMA2.0). In summary, a Requesting 428 Party (Bob) is seeking access to resources belonging to the Resource 429 Owner (Alice) through a Resource Server that Alice controls. 431 The Requesting Party (Bob) selects an ON (e.g. Node #1) to be his 432 Client in the transaction, while the Resource Owner has already 433 activated an ON (e.g. Node #3) to be the Authorization Server that 434 protects the target resource located at the Resource Server (e.g. 435 Node #2). 437 In order for the Requesting Party (Bob) to access the desired 438 resources controlled by the Resource Owner (Alice), two types of 439 exchanges may occur as part of a transaction: 441 o Requesting Party and Client authorization: When the Requesting 442 Party uses the Client (Node #1) to request access to a resource at 443 the Resource Server (Node #2) the Client must obtain an access 444 token from Authorization Server (Node #3). 446 o Requesting Party authentication: In the process of the Client 447 (Node #1) obtaining an access token from the Authorization Server 448 (Node #4), the Client may be directed to the OpenID-Provider (Node 449 #5) for the Requesting Party and Client to be authenticated. 450 (Note that this is part of the claims-gathering flow of UMA). 452 The method for Requesting Party to obtain information regarding the 453 available resources at a given Resource Server is outside the scope 454 of this document. The reader is directed to the UMA2.0 455 specifications. 457 The method of node selection is outside the scope of this document 458 and will be the subject of future specifications. 460 2.7. Exclusivity of UMA-Services 462 For simplicity of design, we propose the exclusive ownership of all 463 UMA-services within an ON node. 465 That is, when a user (e.g. Alice) purchases a ON node offered by an 466 node operator, that ON node is exclusively owned by (and under the 467 full control of) Alice throughout the duration of the contract. The 468 node operator must not advertise otherwise, and other users and 469 entities are able to verify the ownership of a given ON node (i.e. as 470 belonging to Alice) by validating the relevant confirmed smart 471 contract transaction (pertaining to the ON node acquision by Alice 472 from the operator) on the blockchain. 474 2.8. Identifying UMA-Services 476 UMA-Services and their endpoints within a given ON node may be 477 identifed based on the combined public keys related to the UMA- 478 service and the ON unit. The cryptographic hash of the combined UMA- 479 service (e.g. AS-service) public key and the ON unit public key 480 produces a hash-value which can be used to look-up the UMA-service 481 uniquely on a directory or on a blockchain-based naming service. 483 For example, both Alice and Bob may stand-up two distinct ON nodes 484 hosted by the same node operator. Each user may run their own AS- 485 service from within their respective ON nodes. The combined use of 486 the AS service end-point (URI) and these two public keys offer a 487 mechanism to distinguish between Alice's AS from Bob's AS. 489 3. Contracts 491 Contracts form the basis for ON node acquisition (on the 492 infrastructure level) and for resource/data sharing (at the UMA 493 level). ON node acquisition occurs between a user (individual or 494 organization) and an infrastructure node-operator. 496 Resource sharing contracts at the UMA-level capture the licensing of 497 access right to resources belonging to the resource owner. In this 498 sense the current proposal follows the UMA licensing model 499 [UMA-Legal]. 501 Contracts must contain legal prose that bind relevant parties and 502 must contain indicators for dispute resolution. 504 3.1. Contracts definition 506 Contracts are legally binding agreements expressed in digital format 507 that clearly calls out the actors involved in a transaction, the 508 resources (i.e. data) being shared, legal prose (or pointers to legal 509 prose), methods for dispute resolution, and other legal aspects of 510 the transaction. 512 At the infrastructure level, the intent here is to support users 513 (individuals or organizations) to acquire ON node compute-units from 514 an infrastructure node operator in an automated or semi-automated 515 fashion, based on standardized templates of contracts. 517 Similarly, on the UMA level the intent is to support users 518 (individuals or organizations) to acquire licenses for resources in 519 an automated or semi-automated fashion. 521 For example, when Bob seeks to access resources belonging to Alice, 522 Bob's node operator (e.g. BNO Corp) and Alice's node operator (e.g. 523 ANO Corp) are involved in the transaction. 525 This is because when resources (e.g. data) are accessed by Bob and 526 flows from Alice's RS to Bob's Client, the node-operator of Bob's 527 Client (namely BNO Corp) may be able to obtain unauthorized access to 528 those resource. The contract must protect against this possible 529 unauthorized access. 531 3.2. Smart Contracts 533 A smart contract is a set of promises, specified in digital form, 534 including protocols within which the parties perform on these 535 promises. A smart contract should have the following features [NRF]: 537 o Digital form: it is in computer form - code, data and running 538 programs. 540 o Embedded: contractual clauses (or equivalent functional outcomes) 541 are embedded as computer code in software. 543 o Performance mediated by technological means: the release of 544 payments and other actions are enabled by technology and rules- 545 based operations. 547 o Irrevocable: once initiated, the outcomes for which a smart 548 contract is encoded to perform cannot typically be stopped (unless 549 an outcome depends on an unmet condition). 551 Contracts are digitally signed by the relevant parties and may be 552 recorded to a blockchain system or distributed ledger system. A 553 smart contract containing code and legal prose may be used to 554 automate the service agreement process. 556 For ON nodes, the smart contract defining the ON node acquisition 557 agreement must also specify the post-termination actions to be 558 performed by the node-operator on the user's ON node. This agreement 559 clause must define the transferal mechanism for resources and 560 services within the user's ON node. For example, the objects and 561 relevant assets (e.g. data; keys; tokens; etc.) could be packaged and 562 off-loaded to a location designated by the user in the smart 563 contract, such as another node or offline storage. 565 3.3. Types of Contracts 567 We propose distinguishing two (2) types of contracts: 569 o ON node acquisition contract: A ON node acquisition contract 570 denotes the acquisition of specific ON node as a compute-unit by a 571 user (individual or organization) from a given infrastructure node 572 operator. ON node acquisition contracts are typically bilateral 573 between a user and a node-operator. 575 o Resource sharing contract: A resource sharing contract denotes the 576 granting of license by a Resource Owner (to data or resources) to 577 a Requesting Party using the services rendered by infrastructure 578 node operator. See [UMA-Legal]. 580 Parties that transact at the UMA-level through a resource sharing 581 contract must verify that (a) the counterparty posseses valid 582 contracts with their operators, and (b) that the operator contract 583 prohibits the operator from performing unathorized access to the 584 shared resources at the UMA-level. 586 3.4. ON node acquisition contracts: parameters 588 The following are some parameters needed within ON node acquisition 589 contracts: 591 o Type of contract ('ON node acquisition') 593 o Identifier of the user (individual or organization) 595 o Public key of the user 597 o Identifier of the ON node operator 598 o Public key of the ON node operator 600 o Version of ON node (i.e. container/image) and hash 602 o ON unit public-key 604 o ON unit identifier (e.g. URI) 606 o Exclusivity 608 o Duration of service 610 o End-of-contract actions 612 o Service fees and payment mechanism (optional) 614 o Dispute resolution method 616 o Legal prose 618 o Code (for smart contract embodiment) 620 o Timestamp 622 o Archive location of this contract (optional) 624 o Contract template identifier and author (optional) 626 o Target blockchain (for smart contract embodiment) 628 o Signature of User (individual or organization) 630 o Signature of node-operator 632 3.5. Resource sharing contracts: parameters 634 The following are some parameters needed within a resources sharing 635 contract based on the usage of ON nodes. Note that this contract 636 involves only the following UMA-entities: Requesting Party, Client, 637 Client node-operator, Resource Owner, Resource Server, Resource- 638 Server node operator, Authorization Server, Authorization-Server node 639 operator. Other flows and contracts will be addressed in future 640 documents. 642 o Type of contract ('resource sharing') 644 o UMA-services involved (identifier and public-key): RqP, Client, 645 AS, RS, RO 647 o Hash and pointer to the node acquisition contract between the 648 Client-owner and their node-operator. 650 o Hash and pointer to the node acquisition contract between the RO- 651 entity and the node-operator running the ON unit contaning their 652 Resource Server. 654 o Hash and pointer to the node acquisition contract between the AS- 655 owner and the node-operator running the ON unit contaning their 656 Authorization Server. 658 o Duration of data sharing contract 660 o End-of-contract actions 662 o Service fees and payment mechanism (optional) 664 o Dispute resolution method 666 o Legal Prose 668 * Data sharing license 670 o Code (for smart contract embodiment) 672 o Timestamp 674 o Archive location of this contract (optional) 676 o Contract template identifier and author (optional) 678 o Target blockchain (for smart contract embodiment) 680 o Signature of Requesting Party 682 o Signature of Resource Owner data 684 4. Contracts Server in the UMA Context 686 Contracts form the basis for ON node acquisition (on the 687 infrastructure level) and for resource/data sharing (at the UMA 688 level). ON node acquisition occurs between a user (individual or 689 organization) and an infrastructure node-operator. 691 Resource sharing contracts at the UMA-level capture the licensing of 692 access right to resources belonging to the resource owner. In this 693 sense the current proposal follows the UMA licensing model 694 [UMA-Legal]. 696 Contracts must contain legal prose that bind relevant parties and 697 must contain indicators for dispute resolution. 699 4.1. The Contracts server 701 The Contract Server (CS) is a new functional capability introduced 702 into this architecture that did not previously exist in the OAuth2.0, 703 OIDC1.0 or UMA2.0 designs. 705 The contracts server is present at an ON node regardless of which 706 types of UMA-services are activated by the user (node owner). A 707 contracts server in an ON node only serves that node (i.e. it serves 708 the UMA-services active in that ON node). A contracts server cannot 709 be used by services outside its ON node. 711 Some of the core tasks of the contracts server on a node are as 712 follows: 714 o Locate and validate templates of standard contracts 716 o Interact with peer contracts server at other nodes (data sharing 717 contracts) 719 o Validate incoming contracts against standard template contracts 721 o Validate signatures on incoming contracts 723 o Sign contracts using the relevant private keys 725 o Record signed contract to blockchain (using Blockchain Client) 727 o Locate and validate executable-code related to a smart-contract. 729 Similar to endpoints in the UMA-services within an ON node, the 730 contracts server exposes a number of endpoints relevant to completing 731 contracts agreement (e.g. for resource sharing contracts). 733 4.2. Contracts Sub-Flow in the UMA Flow 735 There are several possible uses of the contracts server in the 736 context of the UMA flows. 738 For requesting access to protected resources (at the UMA level), the 739 role of the contracts server is to record the signed agreement 740 between the Requesting Party, Client and the Resource Owner prior to 741 the Authorization Server issuing an RPT token (Requesting Party 742 Token) to the Requesting Party. 744 That is, the contracts server injects a sub-flow within the UMA 745 resource access flow. 747 More specifically, when the Requesting Party (Bob) uses a Client (in 748 Node #1 owned by Carol) to request access to Alice's resources at the 749 Resource Server (in Node #2 owned by Alice), the contracts server 750 belonging to Alice (in Node 2) must perform the following: 752 a. It must prompt the Requesting Party (Bob), namely a human person, 753 to sign the license agreement pertaining to the protected 754 resources belonging to Alice. 756 b. It must search for (on the blockchain) the valid ON node 757 acquisition contract between Carol and her node operator. This 758 indicates that Carol is truly the legal owner of the ON unit 759 (Node #1) running the Client. 761 c. It must engage the contracts server in Node #1 belonging to Carol 762 to sign the license agreement pertaining to the protected 763 resources belonging to Alice. (Note that Alice's license may 764 already be defined a smart contract sitting on her chosen 765 blockchain system). Both contracts server must record the signed 766 agreement to the same blockchain system, with Alice's contracts 767 server have first choice in the selection of the blockchain 768 system.. 770 d. If the ON node acquisition contract for Carol's ON unit (Node #1) 771 did not provide legal coverage against her operator eavesdropping 772 (i.e. stealing data or resources), then Alice's contracts server 773 must engage Carol's node-operator to sign a license agreement 774 suitable for the operator. 776 Only after the respective contracts servers have completed the 777 license agreement and have these recorded on the blockchain (or have 778 it executed on the blockchain), should the RPT token issuance flow 779 continue. 781 Note that in the UMA context the resource sharing license may have a 782 long duration, which means that the above license signing sub-flow 783 need not be repeated if the license contracts are still valid and 784 unrevoked. 786 4.3. Revoking a resource sharing license 788 Once of the key value proposition of UMA is the revocation of 789 licenses, which is in-line with a number of requirements in the GDPR. 791 In the case of license revocation, Alice instructs her contracts 792 server to issue a license-revocation transaction (LRT) to the same 793 blockchain where the original license was created or executed. 795 The license-revocation transaction must point to (i.e. include the 796 hash) of the original license. . 798 4.4. Cascading revocations 800 It is relevant to note that when Alice revokes access to Bob (the 801 Requesting Party), Alice has the option to also revoke both the 802 license contract with Carol (the owner of the Node #1 running the 803 Client used by Bob) and the license contract with the node-operator 804 of Carol's ON node (operator of Node #1). 806 In this scenario, Alice's contracts server must issue several 807 license-revocation transactions on the blockchain to terminate these 808 license contracts. 810 However, Alice has the option to retain the (long term) license 811 contract with Carol (owner of the Client in Node #1) and the operator 812 of Node #1. Alice may do this, for example, in anticipation of other 813 future Requesting Parties using the same Client owned by Carol (e.g. 814 the Client is an extremely popular social media client). 816 5. Design Issues and Challenges 818 There are a number of design issues and challenges with the 819 decentralized service architecture, arising from the need to achieve 820 the goals of (i) decentralization of services, (ii) portability of 821 data and services, and (iii) automated service-provisioning through 822 contracts. Some of these issues are discussed below (not an 823 exhaustive list). 825 5.1. Instrumentation of nodes 827 One key question pertains to the instrumentation of ON nodes. A user 828 (potential owner of an ON node) should be able to acquire an ON node 829 with relative ease through the proper instrumentation tools that 830 common today. A node acquisition contract should specify the tools 831 and services available to the user to instrument and control their ON 832 nodes. 834 Alternate models maybe explored, including the use of a manageability 835 node that represents the user's launch-pad and control point for 836 their entire network of ON nodes. 838 5.2. Protection of private keys 840 An important aspect of systems employing public-key cryptography is 841 the protection of the private-keys. Thus, Alice as the owner of a 842 given ON node must protect the keys associated with all the UMA- 843 services (plus the BC and CS) in her ON node. 845 5.3. Throughput of smart contracts agreement 847 Speed of processing smart contracts (e.g. licnese agreement between 848 to CS servers) is an important aspect because the main UMA flow may 849 be blocking or waiting for the contracts sub-flow to complete. 851 5.4. Moving ON nodes across providers 853 In order to achieve true independence from any given service 854 provider, the owner of a given ON must be able to `move' his or her 855 ON node (together with all the internal relevant resources and 856 configurations) to a new ON node at a new node-operator. 858 Several issues remain open, ranging from a standardized packaging 859 format to the need to re-generate some identifiers for the UMA- 860 services (i.e. new ON node is assigned a new ON unit public key by 861 the new node-operator). 863 Her, there is a role for the Proxy/Forwarder Service in an ON node as 864 way to redirect requests to the new ON node while the old ON node is 865 being shut-down. 867 6. IANA Considerations 869 TBD. 871 7. Security Considerations 873 This document pertains to a peer-to-peer infrastructure for resource 874 sharing based on the UMA model using digital contractsand licenses. 875 As such, there are numerous security aspect of deployments that need 876 to be considered. 878 Aside from known traditional security challenges (e.g. channel 879 binding to keys), there are new security questions that arise due to 880 the proposed use of a peer-to-peer network of nodes as the basis for 881 a decentralized service architecture. Some interesting issues 882 include: 884 Proof of correct execution: One of the security challenges involves 885 obtaining evidence that a node has not deviated from the agreed 886 behavior (as defined in a contract) and has not created side- 887 effects (intentional or unintentional). 889 Proof of data erasure: For a node that act as a resource server 890 holding data belonging to the resource owner, there is a need to 891 provide some mechanism that provides sufficient evidence that data 892 erasure from the node has occurred. Such mechanisms would be 893 useful to parties external to the node, but clearly does not 894 address data copying (data theft) by the node. 896 Correct service definition: When contracts specify certain agreed 897 services (both in node acquisition contracts and resource sharing 898 contracts), there is the question of the correct service semantics 899 being captured in the specified contract, both in the legal prose 900 and within executable code. 902 8. Privacy Considerations 904 This document follows closely the UMA grant of OAuth2.0. The 905 authorization server at an ON comes to be in possession of data/ 906 resource information that may reveal information about the resource 907 owner, which the authorization server's trust relationship with the 908 resource server is assumed to accommodate. 910 The Client and Requesting Party are assumed to be a less-trusted. In 911 fact, these entities are considered entirely untrustworthy until the 912 data sharing contract has been established with the Resource Owner. 914 Following UMA grant of OAuth2.0, the primary privacy duty of the 915 current decentralized design is to the Resource Owner. However, 916 privacy considerations affect the Requesting Party as well. This can 917 be seen in the issuance of an UMA related tokens, which represents 918 the approval of a Requesting Party for a Client (ON) to engage with 919 an Authorization Server to perform tasks needed for obtaining 920 authorization, possibly including pushing claim tokens 922 9. Acknowledgements 924 We thank the following for feedback and inputs on technical and legal 925 aspects (alphabetical last name): Justin Anderson (MIT), James Hazard 926 (IACCM), Cameron Kerry (MIT), Eve Maler (ForgeRock), Alex Pentland 927 (MIT), Tim Reiniger (Future Law). 929 10. References 930 10.1. Normative References 932 [JSON] Bray, T., "The JavaScript Object Notation (JSON) Data 933 Interchange Format", March 2014, 934 . 936 [JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 937 May 2015, . 939 [JWK] Jones, M., "JSON Web Key (JWK)", May 2015, 940 . 942 [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 943 Signature (JWS)", May 2015, 944 . 946 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 947 (JWT)", May 2015, . 949 [OAuth2.0] 950 Hardt, D., "The OAuth 2.0 Authorization Framework", 951 October 2012, . 953 [OIDCCore] 954 Sakimura, N., "OpenID Connect Core 1.0 incorporating 955 errata set 1", November 2014, 956 . 958 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 959 Requirement Levels", BCP 14, RFC 2119, 960 DOI 10.17487/RFC2119, March 1997, 961 . 963 [UMA1.0] Hardjono, T., Maler, E., Machulak, M., and D. Catalano, 964 "User-Managed Access (UMA) Profile of OAuth 2.0", December 965 2015, . 968 [UMA2.0] Maler, E., Machulak, M., and J. Richer, "User-Managed 969 Access (UMA) 2.0", January 2017, 970 . 972 10.2. Informative References 974 [Bitcoin] Nakamoto, S., "Bitcoin: a Peer to Peer Electronic Cash 975 system", 2008, . 977 [BSC-DG] Hardjono, T. and E,. Maler, "Kantara Blockchain and Smart 978 Contract Discussion Group Report", January 2018, 979 . 983 [NRF] Norton Rose Fulbright, "Can Smart Contracts be Legally 984 Binding Contracts", January 2018, 985 . 989 [OIX] "OpenID Exchange", . 991 [OMS] Hardjono, T., Deegan, P., and J. Clippinger, "On the 992 Design of Trustworthy Compute Frameworks for Self- 993 organizing Digital Institutions (HCI 2014)", June 2014, 994 . 997 [OpenPDS] de Montjoye, Y., Wang, S., and A. Pentland, "openPDS: On 998 the Trusted Use of Large-Scale Personal Data (IEEE Data 999 Engineering)", December 2012, 1000 . 1002 [UMA-Legal] 1003 Reiniger, T., "A Proposed Licensing Model for User Managed 1004 Access", January 2018, 1005 . 1008 Author's Address 1010 Thomas Hardjono 1011 MIT 1013 Email: hardjono@mit.edu