idnits 2.17.1 draft-hardjono-oauth-decentralized-01.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 (September 28, 2017) is 2395 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 910, but no explicit reference was found in the text == Unused Reference: 'JWK' is defined on line 917, but no explicit reference was found in the text == Unused Reference: 'JWT' is defined on line 924, but no explicit reference was found in the text == Unused Reference: 'Bitcoin' is defined on line 952, but no explicit reference was found in the text == Unused Reference: 'Eth' is defined on line 960, but no explicit reference was found in the text == Unused Reference: 'OIX' is defined on line 962, but no explicit reference was found in the text == Unused Reference: 'OMS' is defined on line 964, but no explicit reference was found in the text == Unused Reference: 'OpenPDS' is defined on line 970, 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 (~~), 10 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 September 28, 2017 5 Expires: April 1, 2018 7 Decentralized Service Architecture for OAuth2.0 8 draft-hardjono-oauth-decentralized-01 10 Abstract 12 This document proposes an alternative service architecture for user- 13 centric control of the sharing of resources, such as personal data, 14 using the decentralized peer-to-peer computing paradigm. The term 15 'control' is used here to denote the full capacity of the user to 16 freely select (i) the entities with whom to share resources (e.g. 17 data), and (ii) the entities which provide services implementing 18 user-controlled resource sharing. The peer-to-peer service 19 architecture uses a set of computing nodes called OAuth2.0 Nodes (ON) 20 that are part of a peer-to-peer network as the basis for the 21 decentralized service architecture. Each OAuth2.0 Nodes is assumed 22 to have the capability to provide AS-services, RS-services and 23 Client-services. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 1, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. The OAuth2.0 Node . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Node Definition . . . . . . . . . . . . . . . . . . . . . 4 68 2.2. OAuth2.0 Services . . . . . . . . . . . . . . . . . . . . 6 69 2.3. ON Local Functions . . . . . . . . . . . . . . . . . . . 7 70 2.4. Other OAuth2.0 Terminology . . . . . . . . . . . . . . . 7 71 2.5. Transaction Model . . . . . . . . . . . . . . . . . . . . 8 72 2.6. Exclusivity of Services . . . . . . . . . . . . . . . . . 9 73 3. Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 9 75 3.2. Types of Contracts . . . . . . . . . . . . . . . . . . . 10 76 3.3. Service acquisition contracts: fields and parameters . . 10 77 3.4. Data sharing contracts: fields and parameters . . . . . . 11 78 4. Contracts and Blockchain Systems . . . . . . . . . . . . . . 13 79 5. Design Issues and Challenges . . . . . . . . . . . . . . . . 14 80 5.1. Support for subset of services . . . . . . . . . . . . . 14 81 5.2. Contracts expression language . . . . . . . . . . . . . . 14 82 5.3. Contracts server . . . . . . . . . . . . . . . . . . . . 15 83 5.4. Contracts Access Token (CAT) . . . . . . . . . . . . . . 16 84 5.5. Blockchain Client . . . . . . . . . . . . . . . . . . . . 16 85 5.6. Contracts Access Token (CAT) . . . . . . . . . . . . . . 17 86 5.7. Public keys and binding to contracts . . . . . . . . . . 17 87 5.8. End of Contract Actions . . . . . . . . . . . . . . . . . 18 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 90 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 94 10.2. Informative References . . . . . . . . . . . . . . . . . 21 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 97 1. Introduction 99 Today the Identity Provider (IdP) role on the Internet has taken-on a 100 centralized role, due to the predominance of the web single sign-on 101 (Web SSO) model as the basis for the user interaction with services 102 on the Internet. The underlying transaction model of Web SSO has 103 elevated the identity provider to be the single source of trust 104 between the user and the destination service or resource provider 105 (e.g. merchant online). The identity provider has become the toll- 106 gate that mediates the interaction between two transacting parties. 108 This document proposes an alternative decentralized service 109 architecture for user-centric control of the sharing of resources, 110 such as personal data, using the decentralized peer-to-peer computing 111 paradigm. More specifically, we propose a decentralized service 112 architecture for the User Managed Access grant of OAuth (referred to 113 as UMA2.0). 115 The term 'control' is used here to denote the full capacity of the 116 user to freely select (i) the entities with whom to share resources 117 (e.g. data), and (ii) the entities which provide services 118 implementing resource sharing. 120 We propose the use of a peer-to-peer (P2P) service architecture to 121 provide decentralization of services and portability of data, using 122 digital contracts as the legal mechanism to bind service providers: 124 o Decentralization of services: At the infrastructure level, 125 decentralization of service means enabling a user to select the 126 service providers that will provide the user full control over 127 managing access to the user's data, in particular for user-owned 128 data (e.g. stored by user-controlled personal data stores). Here 129 the service providers are entities that provide AS-services, RS- 130 services and Client-services following the UMA2.0 model for user- 131 centric sharing of data. 133 o Portability of data and services: At the data level, 134 decentralization of control means the freedom for the user to 135 switch service providers at any moment in time. As such, 136 portability of data stores and interoperability of services across 137 providers is crucial to allow the user to retain independence from 138 any specific service provider. 140 o Automated service-provisioning through contracts: Decentralization 141 of service and portability of data can be enabled by automation in 142 the provisioning and de-provisioning of services, based on 143 automated contract agreement model. Such an automated model 144 enables users to switch providers rapidly without degradation in 145 control, privacy or sharing levels. Although untested technology, 146 we propose a close alignment of our contracts model with that of 147 "smart contracts" proposed by systems such as Corda [Corda] that 148 employ distributed leger technology (DLT) or blockchain systems. . 150 The P2P service architecture uses a set of computing nodes called 151 OAuth2.0 Nodes (ON) that are part of a peer-to-peer network as the 152 basis for the decentralized service architecture. 154 Each node is assumed to have the capability to provide AS-services, 155 RS-services and Client-services following the UMA2.0 context. 156 Additionally, each node is assumed to also have the capability to 157 provide authentication services for other nodes and for users, 158 following the OpenID-Connect 1.0 model. 160 This document is agnostic as to how OAuth2.0 functions or services 161 are implemented by node operators. A node operator may or may not 162 implemented these services as executable bytecodes (smart contracts). 164 The decentralized architecture is not dependent on any blockchain 165 system. Any contracts agreement mechanism can be deployed between 166 parties, where both parties digitally sign agreed contracts. 168 In the following we describe in more details the functions of the 169 node. The reader is assumed to have familiarity with OAuth2.0 170 [OAuth2.0], OpenID-Connect Core [OIDCCore] and UMA 2.0 [UMA2.0]. 172 2. The OAuth2.0 Node 174 This document proposes the use a peer-to-peer (P2P) network of nodes 175 as the basis for a decentralized service architecture for user- 176 centric management of data sharing and service provisioning. 178 2.1. Node Definition 180 Each node is referred to as an OAuth2.0 Node (ON), and implements the 181 AS-services, RS-services and Client-services following the UMA2.0. 182 Additionally, it implements Authentication Services following 183 OIDC1.0. These services (functions) can be contracted to (leased) by 184 a user to implement resource sharing. The OAuth2.0 Node also has 185 additional infrastructure functions that are used for its own 186 operations and cannot be contracted to by an external entity. 188 We distinguish between a node operator and a node owner. A node 189 operator is the legal owner of the physical system implementing a 190 given node. The node owner is contextual in nature and represents 191 the contracted owner of a function or service at a node. Contractual 192 ownership of a function or service can be exclusive or multi- 193 tenanted, although currently for simplicity we propose an exclusive 194 service agreement 196 Possessing these complete services, a node operator can make 197 available one or more of these services available depending on the 198 context of the transaction, the entity it represents and the entity 199 with whom it is interacting. 201 A user (Resource Owner or Requesting Party) obtains a given OAuth2.0 202 service (e.g. AS-service, RS-service, Client-service) from a given 203 node by entering into a service acquisition contract with the node 204 operator. The service acquisition contract makes the user the 205 "owner" of that service at the node for the duration of the contract. 207 We distinguish between the node operator and the node owner: 209 o Node Operator: The legal owner of the physical system implementing 210 an ON node. 212 o Node Owner: The (logical) owner of service at an ON node acquired 213 for a duration of time under a contract with the node operator. 215 Contracts and digitally signed by the relevant parties and may be 216 recorded to (or executed by) a blockchain system or distributed 217 ledger system, although such actions must be independent from the 218 legal status of contracts. The current service architecture is 219 agnostic to the specific implementation of the underlying blockchain 220 or distributed ledger system. 222 Once a resource owner acquires services from a node (e.g. RS- 223 service), it can participate in transaction with a requesting party 224 following the UMA grant of OAuth2.0. The requesting party may also 225 acquire services (e.g. Client-service) from a node, with the purpose 226 of using that service with a compatible service owned by a resource 227 owner. 229 The public key associated with the service endpoint and the public 230 key associated with the node operator (offering that service) 231 provides a mechanism to detect and prevent conflicts of services. 232 Here, the term 'conflict' is seen from the perspective of the user 233 (resource owner or requesting party). It is used to mean a node that 234 simultaneously contracts an RS-service and a Client-service to 235 competing users. The acceptability of this configuration must be 236 decided by the user prior to contracting any service from a node 237 operator. 239 At the end of the duration of service acquisition contract, both the 240 node and the user (Resource Owner or Requesting Party) must agree on 241 an asset-transferal mechanism in which the user's relevant assets 242 (e.g. data; keys; tokens; etc.) must be offloaded from the node to a 243 location designated by the user, such as another node or offline 244 storage. The default behavior of the node is to erase or flush the 245 user's relevant assets post-transferal and make available the same 246 service to another potential customer (user). 248 +------------------------------------------------+ 249 | | 250 | +----------------+ +----------------+ | 251 | | Authorization | | OpenID-Connect | | 252 | | Server (AS) | | Provider (OP) | | 253 | +----------------+ +----------------+ | 254 | | 255 | +----------------+ +----------------+ | 256 | | Confidential | | Resource | | 257 | | Client (CC) | | Server (RS) | | 258 | +----------------+ +----------------+ | 259 | | 260 | +----------------+ +----------------+ | 261 | | Policy | | Proxy/ | | 262 | | Server (PS) | | Forwarder (PF) | | 263 | +----------------+ +----------------+ | 264 | | 265 | +----------------------------------------+ | 266 | | 267 | +----------------+ +----------------+ | 268 | | Blockchain | | Contracts | | 269 | | Client (BC) | | Server (CS) | | 270 | +----------------+ +----------------+ | 271 | | 272 +------------------------------------------------+ 274 Figure 1: OAuth2.0 Node (ON) 276 2.2. OAuth2.0 Services 278 The following are services that are implemented by an OAuth2.0 Node 279 (ON) which can be contracted to by an external entity from the ON 280 operator: 282 Confidential Client The Confidential Client (CC) is client that 283 possesses capabilities to store secrets, such as cryptographic 284 keys and other confidential parameters. 286 Authorization Server The Authorization Server (AS) is a server that 287 protects resources managed at a resource server on a resource 288 owner's behalf. 290 Resource Server AThe Resource Server (RS) is a server that hosts 291 resources on a Resource Owner's behalf, registers resources for 292 protection at an Authorization Server, and is capable of accepting 293 and responding to requests for protected resources. 295 OpenID Provider The OpenID Provider (OP) implements authentication 296 of the Requesting Party and the Client. In the case of a Client, 297 it performs authentication via proof of possession, either 298 symmetric keys or asymmetric keys per RFC7800. 300 Policy Server The Policy Server (PS) implements the policy 301 administration point (PAP) and policy decision point (PDP) for the 302 Resource Owner, for each resource owned by the Resource Owner. 304 Proxy/Forwarder The Proxy/Forwarder (PF) implements proxying to 305 another node, relying on that node's implementation of the same 306 function. 308 2.3. ON Local Functions 310 The following are services that are implemented by an OAuth2.0 Node 311 (ON) for its own operations and which cannot be contracted to by an 312 external entity: 314 Blockchain Client The Blockchain Client (BC) implements the client 315 role in a blockchain system. This service cannot be contracted to 316 by an external entity. 318 Contracts Server The Contracts Server (CS) implements the contracts 319 management and fulfilment for users and with other ON nodes. This 320 service cannot be contracted to by an external entity. 322 2.4. Other OAuth2.0 Terminology 324 The following is a set of terminologies used in OAuth2.0 and in 325 UMA2.0: 327 Requesting Party The Requesting Party (RqP) is a natural or legal 328 person that uses a client to seek access to a protected resource. 329 The requesting party may or may not be the same party as the 330 resource owner. 332 Resource Owner The Resource Owner (RO) is an entity capable of 333 granting access to a protected resource. This is typically an 334 end-user (a natural person) but it can also be non-human entity 335 that is treated as a person for limited legal purposes (a legal 336 person), such as a corporation. 338 Resource A digital resource available through an HTTP service. 340 Protected resource A resource to which a resource owner is able to 341 control access grants through an authorization server. 343 Scope A bounded extent of access to a protected resource. Scopes 344 are associated with particular resources. 346 Policy Conditions Access grant rules configured at an Authorization 347 Server that effect resource protection. 349 Claim A statement of the value or values of one or more attributes 350 of an entity. 352 Permission Authorized access to a particular resource with one or 353 more scopes. A resource server requests one or more permissions 354 on behalf of a client at an authorization server. 356 2.5. Transaction Model 358 The transaction model follows closely that of the UMA grant of 359 OAuth2.0 (also referred to as UMA2.0). Here a Requesting Party (Bob) 360 is seeking access to resources or services offered by the Resource 361 Owner (Alice) through a Resource Server that Alice controls. 363 The Requesting Party (Bob) selects an ON (e.g. Node #1) to be the 364 Client in the transaction, while the Resource Owner selects an ON 365 (e.g. Node #3) to be the Authorization Server that protects the 366 target resource located at the Resource Server (e.g. Node #2). 368 In order for the Requesting Party (Bob) to access the desired 369 resources controlled by the Resource Owner (Alice), two types of 370 exchanges may occur as part of a transaction: 372 o Requesting Party and Client authorization: When the Requesting 373 Party uses the Client (Node #1) to request access to a resource at 374 the Resource Server (Node #2) the Client must obtain an access 375 token from Authorization Server (Node #3). 377 o Requesting Party authentication: In the process of the Client 378 (Node #1) obtaining an access token from the Authorization Server 379 (Node #4), the Client may be directed to the OpenID-Provider (Node 380 #5) for the Requesting Party to authenticate himself or herself. 382 The method for Requesting Party to obtain information regarding the 383 available resources at a given Resource Server is outside the scope 384 of this document. 386 The method of node selection is outside the scope of this document 387 and will be the subject of future specifications 389 2.6. Exclusivity of Services 391 For simplicity of design, we propose the exclusive ownership of 392 services at all ON nodes for any given time. Furthermore, the node 393 operator must associate a public key with the service endpoint, 394 independent of the current ownership of that service by the user. 396 When a user (Resource Owner or Requesting Party) contracts a service 397 offered by a node operator, that service is exclusively owned by (and 398 under the full control of) the user throughout the duration of the 399 contract. The node operator must not advertise otherwise, and 400 potential users looking for services must verify (e.g. to a 401 blockchain or contracts ledger) that a service point at a node is 402 currently not under contract. 404 The long-term binding of a public key with the service endpoint by 405 the node operator across differing owners allow other users to 406 validate the ownership-status of as given service, and also allows 407 for cryptographic level binding for transport security (e.g. TLS). 409 3. Contracts 411 Contracts form the basis for services acquisition and for data 412 sharing. Services acquisition occurs between a user (Resource Owner 413 or Requesting Party) and a node on the P2P network. Data sharing 414 contracts occur between a Resource Owner and a Requesting Party, 415 implemented through the services that each user contracts from ON 416 operators. 418 Contracts must contain legal prose that bind relevant parties and 419 must contain indicators for dispute resolution. 421 A contract may or may not contain executable code (i.e. smart 422 contract). 424 3.1. Definition 426 Contracts are legally binding agreements expressed in digital format 427 that clearly calls out the actors involved in a transaction, the 428 resources (i.e. data) being shared, legal prose (or pointers to legal 429 prose), methods for dispute resolution, and optionally code or 430 pseudocode that captures the computing functions involved in services 431 acquisition or data sharing. 433 The intent here is that users (Resource Owner or Requesting Party) 434 would acquire services from nodes using bilateral contracts between 435 the user and the node in an automated and semi-automated fashion, 436 based on standardized templates of contracts. 438 Similarly, within a data sharing transaction a Requesting Party would 439 acquire access to data under the control of the Resource Owner by 440 using a 3-party contract. In this case, the contract must identify 441 the Client node (under control of the Requesting Party), the 442 Authorization Server node and the Resource Server node (both under 443 the control of the Resource Owner). 445 3.2. Types of Contracts 447 We propose distinguishing two (2) types of contracts: 449 o Service acquisition contract: A Service acquisition contract 450 denotes the acquisition of specific OAuth2.0 services by a user 451 (Resource Owner or Requesting Party) from a given OAuth2.0 Node 452 operator. Service acquisition contracts are typically bilateral 453 between a user and a OAuth2.0 Node operator. 455 o Data Sharing contract: A data sharing contract denotes the 456 granting of access by a Resource Owner to a data or resource to a 457 Requesting Party using the services of the identified OAuth2.0 458 Node operator. Data sharing contracts typically involve up to 459 five (5) entities: the Requesting Party, the Resource Owner, the 460 operator of the Client ON, the operator of the Authorization 461 Server ON and the operator of the Resource Server ON. 463 A data sharing contract presumes that entities involved have acquired 464 relevant services from ON node operators through bilateral service 465 acquisition contracts 467 3.3. Service acquisition contracts: fields and parameters 469 The following information is needed within a service acquisition 470 contracts: 472 o Type of contract 474 o Identifier of the user (Requesting Party or Resource Owner) 476 o Public key of the user o Identifier of the ON operator 477 o Public key of the ON operator 479 o Public key of the service endpoint 481 o Type of service provided (e.g. Client, RS, AS, OP, PS) 483 o Exclusivity 485 o Duration of service 487 o End-of-contract actions 489 o Service fees and payment mechanism (optional) 491 o Dispute resolution method 493 o Legal prose 495 o Code or pseudocode (optional) 497 o Timestamp o Archive location of this contract (optional) 499 o Contract template identifier and author (optional) 501 o Target blockchain (optional) 503 o Signature of User 505 o Signature of ON operator 507 3.4. Data sharing contracts: fields and parameters 509 The following information is needed within a data sharing contract: 511 o Type of contract 513 o Requesting Party: 515 * Identifier of the Requesting Party 517 * Public key of the Requesting Party 519 o Client: 521 * Identifier of the Client ON operator 523 * Client service endpoints 524 * Public key of the Client ON operator 526 * Public key of the Client service at the ON 528 o Resource Owner: 530 * Identifier of the Resource Owner 532 * Public key of the Resource Owner 534 o Resource Server: 536 * Identifier of the Resource Server ON operator 538 * RS service endpoints 540 * Public key of the Resource Server ON operator 542 * Public key of the RS service endpoint at the ON 544 o Authorization Server: 546 * Identifier of the Authorization Server ON operator 548 * AS service endpoints 550 * Public key of the Authorization Server ON operator 552 * Public key of the AS service endpoint at the ON 554 o Duration of data sharing contract 556 o End-of-contract actions 558 o Service fees and payment mechanism (optional) 560 o Dispute resolution method 562 o Legal Prose 564 * Data sharing terms and conditions 566 o Code or pseudocode (optional) 568 o Timestamp 570 o Archive location of this contract (optional) 571 o Contract template identifier and author (optional) 573 o Target blockchain (optional) 575 o Signature of Requesting Party 577 o Signature of Resource Owner data 579 4. Contracts and Blockchain Systems 581 Blockchain technology offers interesting possibilities with regards 582 to the notarization of contracts (for non-programmatic or "dumb" 583 contracts) and with the regards to execution of code that may be 584 embedded within programmatic contracts (smart contracts). In both 585 cases, public key digital signatures represents a core function to 586 provide source-authenticity of contracts. 588 The proposed decentralized service architecture based on the peer-to- 589 peer computing paradigm is independent from any given blockchain 590 system, and independent of the permissions of blockchains 591 (permissioned or public). 593 In this context, we recognize two broad families of blockchains 594 systems that are relevant to our transaction model or pattern: 596 o Application-specific blockchain system (non-programmatic): The 597 blockchain is designed to perform specific tasks which cannot be 598 extended or modified. Examples include the Bitcoin blockchain 599 system designed for a digital currency application. 601 o Application-loadable blockchain system (programmatic): The 602 blockchain support the notion of executable code running in one or 603 more of the nodes of the blockchain, where the executable code can 604 be programmed, loaded & offloaded, according to the intended 605 application. The ledger function is integrated into the node, and 606 as such records the results of the execution of the application. 607 Such nodes may use virtual machine (VM) technology to achieve this 608 effect. Examples include the Ethereum platform 610 For the purposes of contract adherence and fulfilment, both families 611 of blockchains systems can provide assistance to OAuth2.0 Nodes (ON) 612 in fulfilling the transaction model stated above (resource sharing 613 from Alice to Bob). The assistance available to nodes corresponds to 614 the blockchain system type being: 616 o Contract notarization and archiving: Entities who participate in 617 service acquisition contracts or data sharing contracts can make 618 use of a suitable non-programmatic blockchain system to keep a 619 (public) log of a signed contract. This can be done by storing a 620 cryptographic hash of the contract within the transaction records 621 of the ledger of the blockchain system. Systems such as the 622 Bitcoin blockchain has some limited capacity to perform this 623 function though the blockchain was not intended for use as a 624 generic log for record keeping. 626 o Data sharing flow execution and notarization: Nodes that have the 627 capability to receive, load and execute code found in contracts 628 may choose to run parts or all of the service function (Client- 629 service AS-service, or RS-service) within its virtual machine 630 space instead of the general compute space of the node hardware. 632 o Dispute resolution: Disputes may occur even for completed and 633 archived contracts. Blockchains offer the possibility of 634 providing a common medium to capture evidence regarding a 635 contract. 637 The proposed decentralized service architecture does not require 638 OAuth2.0 Node (ON) operators to implement the OAuth2.0 services in 639 the form of executable code running in one or more of the nodes of 640 the blockchain. 642 5. Design Issues and Challenges 644 There are a number of design issues and challenges with the 645 decentralized service architecture, arising from the need to achieve 646 the goals of (i) decentralization of services, (ii) portability of 647 data and services, and (iii) automated service-provisioning through 648 contracts. Some of these are discussed below. 650 5.1. Support for subset of services 652 The proposed decentralized service architecture does not require 653 OAuth2.0 Node (ON) operators to implement and make available all 654 services. An operator is free to choose all or a subset of services. 656 The method used for an ON to advertise available services is outside 657 the scope of the current document. 659 5.2. Contracts expression language 661 The current decentralized service architecture proposes the use of a 662 JSON-based contract, which makes use the JOSE family cryptographic 663 services for JSON (e.g. signing, encryption, key identification). 664 See [JWS] and [JWE]. 666 Such a JSON-based contract will be the subject of a future 667 specification. 669 5.3. Contracts server 671 The Contract Server (CS) is a new functional capability introduced 672 into this architecture that did not previously exist in the OAuth2.0, 673 OIDC1.0 or UMA2.0 designs. 675 The contracts server is present at an OAuth2.0 Node (ON) regardless 676 of whether the node implements all the OAuth2.0 services or only a 677 subset of these services. The contracts server function cannot be 678 leased-out to users or other entities, and represents an operational 679 infrastructure component for an ON. 681 For a data sharing contract between a Requesting Party (employing a 682 Client node) and the Resource Owner (employing an AS node), the 683 contracts servers as the Client node and the AS node perform the 684 relevant contracts-related tasks. 686 Some of the core tasks of the contracts server on a node are as 687 follows: 689 o Locate and validate templates of standard contracts (optional) 691 o Interact with peer contracts server at other nodes (data sharing 692 contracts) 694 o Validate incoming contracts against standard template contracts 696 o Validate signatures on incoming contracts 698 o Sign contracts using the relevant private keys 700 o Record signed contract to blockchain (optional) 702 o Deliver the executable-code (found in the agreed contract) to the 703 relevant underlying blockchain-related component on the node 704 (optional). 706 Similar to endpoints in the UMA grant of OAuth2.0, the contracts 707 server exposes a number of endpoints relevant to completing contracts 708 agreement for service acquisition contracts and for data sharing 709 contracts. 711 The same endpoints should be used by callers for both service 712 acquisition contracts and data sharing contracts. The type of 713 contract being presented by the caller must be clear from the type- 714 of-contract field. 716 5.4. Contracts Access Token (CAT) 718 A data sharing contract may come into existence as part of a Client's 719 access attempt to a data/resource located at a Resource Server. When 720 the Client is redirected to the AS in order to obtain an access token 721 from the AS, the Client (and Requesting Party) may be required to 722 complete a data sharing contract through a separate flow (sub-flow) 723 with the contracts server. In this case, the default contracts 724 server is that belonging to (underlying) the AS. 726 The contracts server itself may be a protected resource, access to 727 which requires a special access token from the AS. For ease of 728 understanding, we refer to this token as the Contract Access Token 729 (CAT). Note that the CAT is similar to the PAT token in the UMA 730 context. 732 The Client must first obtain a CAT from the AS prior to engaging the 733 contracts server. After obtaining a CAT from the AS, the Client (or 734 more correctly the Client's own contracts server) presents the CAT to 735 the contracts server at the AS together with a proposed contract or 736 contract template identifier. 738 The contracts server at the AS validates both the CAT and the 739 proposed contract (or template), completes the necessary fields (e.g. 740 the RS location, endpoint and public key), signs it and returns it to 741 the Client. The Client must validate the received contract, counter- 742 signs it and returns it to the contracts server at the AS. 744 After the contracts server at the AS validate the integrity and 745 signature of the contract, it may optionally record it on the 746 blockchain or distributed ledger. 748 The AS then issues the Client with the relevant access token (per 749 UMA2.0 flows) to present to the RS. The access token specifies the 750 resources available to the Client and Requesting Party following the 751 agreed contract. It may optionally include pointers to the contract, 752 meaningful only to the AS (i.e. in the case of token validation). 754 5.5. Blockchain Client 756 The Blockchain Client (BC) is a new functional capability introduced 757 into this architecture that did not previously exist in the OAuth2.0, 758 OIDC1.0 or UMA2.0 designs. 760 The blockchain client interacts with the relevant underlying 761 blockchain systems or distributed ledger system shared between the 762 Requesting Party and the Resource Owner. 764 The blockchain client is used by the contract server within an 765 OAuth2.0 Node to transmit blockchain-transaction to the target 766 blockchain system. It is also used by the node to validate the 767 existence of a given previous transaction on the blockchain. 769 The blockchain client may also be used for payments related to 770 service acquisition contracts (e.g. between a user and an ON 771 operator) and to data sharing contracts (e.g. Requesting Party 772 paying Resource Owners). 774 5.6. Contracts Access Token (CAT) 776 The current decentralized service architecture proposes the use of a 777 JSON-based contract, which makes use the JOSE family cryptographic 778 services for JSON (e.g. signing, encryption, key identification). 780 Such a JSON-based contract will be the subject of a future 781 specification. 783 5.7. Public keys and binding to contracts 785 Public key cryptography plays an important role in contracts due to 786 its ability to provide technical-trust (through proof-of-possession 787 and strength of the chosen public-key cryptosystem) and to provide 788 legal-trust through the legal acceptance of digital-signatures as 789 legal signatures (i.e. Digital Signature Act). 791 Node operators must possess the following public key pairs in order 792 to support the proposed decentralized model: 794 o Operator-level public key: A node operator must possess an 795 operator level public key that it uses to legally sign contracts. 796 This public key must be long-term and be legally associated/owned 797 by the operator (e.g. through a CA-issued certificate). 799 o Service endpoint public keys: For each OAuth2.0 service supported, 800 the node operator must associate and bind a unique long-term 801 public key to that service 803 Public key pairs are used in this architecture for the following: 805 o Contracts signing: the public-key pair is used to digitally signed 806 a contract by entities involved in a service acquisition contract 807 or data sharing contract. 809 o Service endpoint authentication: the public-key pair is used to 810 authenticate a service end-point and to cryptographically bind the 811 secure channel to the session between the caller and the service 812 end-point (e.g. see RFC5929 and RFC5056) 814 o Access to blockchain: the public-key pair of a service endpoint 815 can used to submit a transaction to a blockchain or distributed 816 ledger system, where the system accepts the transaction as source- 817 authenticated. 819 o Contracts execution (smart contracts): the public-key pair is used 820 by the a blockchain or distributed ledger system to execute the 821 code (e.g. bytecode) found within a contract and where the public- 822 key is invoked by the executing code 824 5.8. End of Contract Actions 826 At the end of a contract period, an OAuth2.0 Node (ON) must perform 827 post-contract action as specified in the contract (service 828 acquisition contract and data sharing contract). These post-contract 829 action may or may not be recorded in some manner through a blockchain 830 to provide evidence of its own completion. 832 Examples of end-of-contract actions include transferring data to 833 another repository (e.g. to another RS), flushing all user data 834 cached at the node, claiming payments (e.g. at a payments escrow 835 party), and so on. 837 The end-of-contract actions will be the subject t of a future 838 specification. 840 6. IANA Considerations 842 TBD. 844 7. Security Considerations 846 This document pertains to a peer-to-peer infrastructure for data 847 sharing based on digital contracts. As such, there are numerous 848 security aspect of deployments that need to be considered. 850 Aside from known traditional security challenges (e.g. channel 851 binding to keys), there are new security questions that arise due to 852 the proposed use of a peer-to-peer network of nodes as the basis for 853 a decentralized service architecture. Some interesting issues 854 include: 856 Proof of correct execution: One of the security challenges involves 857 obtaining evidence that a node has not deviated from the agreed 858 behavior (as defined in a contract) and has not created side- 859 effects (intentional or unintentional). 861 Proof of data erasure: For a node that act as a resource server 862 holding data belonging to the resource owner, there is a need to 863 provide some mechanism that provides sufficient evidence that data 864 erasure from the node has occurred. Such mechanisms would be 865 useful to parties external to the node, but clearly does not 866 address data copying (data theft) by the node. 868 Correct service definition: When contracts specify certain agreed 869 services (both in service acquisition contracts and data sharing 870 contracts), there is the question of the correct service semantics 871 being captured in the contract, both in the legal prose and within 872 executable code (or pseudocode). 874 8. Privacy Considerations 876 This document follows closely the UMA grant of OAuth2.0. The 877 authorization server at an ON comes to be in possession of data/ 878 resource information that may reveal information about the resource 879 owner, which the authorization server's trust relationship with the 880 resource server is assumed to accommodate. 882 The Client and Requesting Party are assumed to be a less-trusted. In 883 fact, these entities are considered entirely untrustworthy until the 884 data sharing contract has been established with the Resource Owner. 886 Following UMA grant of OAuth2.0, the primary privacy duty of the 887 current decentralized design is to the Resource Owner. However, 888 privacy considerations affect the Requesting Party as well. This can 889 be seen in the issuance of an UMA related tokens, which represents 890 the approval of a Requesting Party for a Client (ON) to engage with 891 an Authorization Server to perform tasks needed for obtaining 892 authorization, possibly including pushing claim tokens 894 9. Acknowledgements 896 The following people made significant contributions to the contents 897 of this document: 899 o Christian Smith (MIT) 901 o Dmitri Zagidulin (MIT) 903 o Greg Linklater (Rhodes University) 904 o Eve Maler (ForgeRock) 906 10. References 908 10.1. Normative References 910 [JSON] Bray, T., "The JavaScript Object Notation (JSON) Data 911 Interchange Format", March 2014, 912 . 914 [JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 915 May 2015, . 917 [JWK] Jones, M., "JSON Web Key (JWK)", May 2015, 918 . 920 [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 921 Signature (JWS)", May 2015, 922 . 924 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 925 (JWT)", May 2015, . 927 [OAuth2.0] 928 Hardt, D., "The OAuth 2.0 Authorization Framework", 929 October 2012, . 931 [OIDCCore] 932 Sakimura, N., "OpenID Connect Core 1.0 incorporating 933 errata set 1", November 2014, 934 . 936 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 937 Requirement Levels", BCP 14, RFC 2119, 938 DOI 10.17487/RFC2119, March 1997, 939 . 941 [UMA1.0] Hardjono, T., Maler, E., Machulak, M., and D. Catalano, 942 "User-Managed Access (UMA) Profile of OAuth 2.0", December 943 2015, . 946 [UMA2.0] Maler, E., Machulak, M., and J. Richer, "User-Managed 947 Access (UMA) 2.0", January 2017, 948 . 950 10.2. Informative References 952 [Bitcoin] Nakamoto, S., "Bitcoin: a Peer to Peer Electronic Cash 953 system", 2008, . 955 [Corda] Brown, R., Carlyle, J., Grigg, I., and M. Hearn, "Corda: 956 An Introduction", August 2016, 957 . 960 [Eth] "Ethereum.org", . 962 [OIX] "OpenID Exchange", . 964 [OMS] Hardjono, T., Deegan, P., and J. Clippinger, "On the 965 Design of Trustworthy Compute Frameworks for Self- 966 organizing Digital Institutions (HCI 2014)", June 2014, 967 . 970 [OpenPDS] de Montjoye, Y., Wang, S., and A. Pentland, "openPDS: On 971 the Trusted Use of Large-Scale Personal Data (IEEE Data 972 Engineering)", December 2012, 973 . 975 Author's Address 977 Thomas Hardjono 978 MIT 980 Email: hardjono@mit.edu