OAuth Working Group T. Hardjono Internet-Draft MIT Intended status: Informational September 28, 2017 Expires: April 1, 2018 Decentralized Service Architecture for OAuth2.0 draft-hardjono-oauth-decentralized-01 Abstract This document proposes an alternative service architecture for user- centric control of the sharing of resources, 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. Each OAuth2.0 Nodes is assumed to have the capability to provide AS-services, RS-services and Client-services. 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 April 1, 2018. Hardjono Expires April 1, 2018 [Page 1] Internet-Draft Decentralized OAuth September 2017 Copyright Notice Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Node Definition . . . . . . . . . . . . . . . . . . . . . 4 2.2. OAuth2.0 Services . . . . . . . . . . . . . . . . . . . . 6 2.3. ON Local Functions . . . . . . . . . . . . . . . . . . . 7 2.4. Other OAuth2.0 Terminology . . . . . . . . . . . . . . . 7 2.5. Transaction Model . . . . . . . . . . . . . . . . . . . . 8 2.6. Exclusivity of Services . . . . . . . . . . . . . . . . . 9 3. Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Types of Contracts . . . . . . . . . . . . . . . . . . . 10 3.3. Service acquisition contracts: fields and parameters . . 10 3.4. Data sharing contracts: fields and parameters . . . . . . 11 4. Contracts and Blockchain Systems . . . . . . . . . . . . . . 13 5. Design Issues and Challenges . . . . . . . . . . . . . . . . 14 5.1. Support for subset of services . . . . . . . . . . . . . 14 5.2. Contracts expression language . . . . . . . . . . . . . . 14 5.3. Contracts server . . . . . . . . . . . . . . . . . . . . 15 5.4. Contracts Access Token (CAT) . . . . . . . . . . . . . . 16 5.5. Blockchain Client . . . . . . . . . . . . . . . . . . . . 16 5.6. Contracts Access Token (CAT) . . . . . . . . . . . . . . 17 5.7. Public keys and binding to contracts . . . . . . . . . . 17 5.8. End of Contract Actions . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 Hardjono Expires April 1, 2018 [Page 2] Internet-Draft Decentralized OAuth September 2017 1. Introduction Today the Identity Provider (IdP) role on the Internet has taken-on a centralized role, due to the predominance of the web single sign-on (Web SSO) model as the basis for the user interaction with services on the Internet. The underlying transaction model of Web SSO has elevated the identity provider to be the single source of trust between the user and the destination service or resource provider (e.g. merchant online). The identity provider has become the toll- gate that mediates the interaction between two transacting parties. 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 for the User Managed Access grant of OAuth (referred to as UMA2.0). 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 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 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 full control over managing access to the user's data, in particular for user-owned data (e.g. stored by user-controlled personal data stores). Here the service providers are entities that provide AS-services, RS- services and Client-services following the UMA2.0 model for user- centric sharing of data. o Portability of data and services: At the data level, decentralization of control means the freedom for the user to switch service providers at any moment in time. As such, portability of data stores 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 automated contract agreement model. Such an automated model enables users to switch providers rapidly without degradation in Hardjono Expires April 1, 2018 [Page 3] Internet-Draft Decentralized OAuth September 2017 control, privacy or sharing levels. Although untested technology, we propose a close alignment of our contracts model with that of "smart contracts" proposed by systems such as Corda [Corda] that employ distributed leger technology (DLT) or blockchain systems. . The P2P 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. Each node is assumed to have the capability to provide AS-services, RS-services and Client-services following the UMA2.0 context. Additionally, each node is assumed to also have the capability to provide authentication services for other nodes and for users, following the OpenID-Connect 1.0 model. This document is agnostic as to how OAuth2.0 functions or services are implemented by node operators. A node operator may or may not implemented these services as executable bytecodes (smart contracts). The decentralized architecture is not dependent on any blockchain system. Any contracts agreement mechanism can be deployed between parties, where both parties digitally sign agreed contracts. In the following we describe in more details 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 implements the AS-services, RS-services and Client-services following the UMA2.0. Additionally, it implements Authentication Services following OIDC1.0. These services (functions) can be contracted to (leased) by a user to implement resource sharing. The OAuth2.0 Node also has additional infrastructure functions that are used for its own operations and cannot be contracted to by an external entity. We distinguish between a node operator and a node owner. A node operator is the legal owner of the physical system implementing a given node. The node owner is contextual in nature and represents the contracted owner of a function or service at a node. Contractual ownership of a function or service can be exclusive or multi- Hardjono Expires April 1, 2018 [Page 4] Internet-Draft Decentralized OAuth September 2017 tenanted, although currently for simplicity we propose an exclusive service agreement Possessing these complete services, a node operator can make available one or more of these services available depending on the context of the transaction, the entity it represents and the entity with whom it is interacting. A user (Resource Owner or Requesting Party) obtains a given OAuth2.0 service (e.g. AS-service, RS-service, Client-service) from a given node by entering into a service acquisition contract with the node operator. The service acquisition contract makes the user the "owner" of that service at the node for the duration of the contract. We distinguish between the node operator and the node owner: o Node Operator: The legal owner of the physical system implementing an ON node. o Node Owner: The (logical) owner of service at an ON node acquired for a duration of time under a contract with the node operator. Contracts and digitally signed by the relevant parties and may be recorded to (or executed by) a blockchain system or distributed ledger system, although such actions must be independent from the legal status of contracts. The current service architecture is agnostic to the specific implementation of the underlying blockchain or distributed ledger system. Once a resource owner acquires services from a node (e.g. RS- service), it can participate in transaction with a requesting party following the UMA grant of OAuth2.0. The requesting party may also acquire services (e.g. Client-service) from a node, with the purpose of using that service with a compatible service owned by a resource owner. The public key associated with the service endpoint and the public key associated with the node operator (offering that service) provides a mechanism to detect and prevent conflicts of services. Here, the term 'conflict' is seen from the perspective of the user (resource owner or requesting party). It is used to mean a node that simultaneously contracts an RS-service and a Client-service to competing users. The acceptability of this configuration must be decided by the user prior to contracting any service from a node operator. At the end of the duration of service acquisition contract, both the node and the user (Resource Owner or Requesting Party) must agree on Hardjono Expires April 1, 2018 [Page 5] Internet-Draft Decentralized OAuth September 2017 an asset-transferal mechanism in which the user's relevant assets (e.g. data; keys; tokens; etc.) must be offloaded from the node to a location designated by the user, such as another node or offline storage. The default behavior of the node is to erase or flush the user's relevant assets post-transferal and make available the same service to another potential customer (user). +------------------------------------------------+ | | | +----------------+ +----------------+ | | | 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) which can be contracted to by an external entity from the ON operator: Confidential Client The Confidential Client (CC) is client that possesses capabilities to store secrets, such as cryptographic keys and other confidential parameters. Hardjono Expires April 1, 2018 [Page 6] Internet-Draft Decentralized OAuth September 2017 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 AThe 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 protected resources. OpenID Provider The OpenID Provider (OP) implements authentication of the Requesting Party and the Client. In the case of a Client, it performs authentication via proof of possession, either symmetric keys or asymmetric keys per RFC7800. 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 which cannot be contracted to by an external entity: Blockchain Client The Blockchain Client (BC) implements the client role in a blockchain system. This service cannot be contracted to by an external entity. Contracts Server The Contracts Server (CS) implements the contracts management and fulfilment for users and with other ON nodes. This service cannot be contracted to by an external entity. 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 Hardjono Expires April 1, 2018 [Page 7] Internet-Draft Decentralized OAuth September 2017 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. 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. Transaction Model The transaction model follows closely that of the UMA grant of OAuth2.0 (also referred to as UMA2.0). Here a Requesting Party (Bob) is seeking access to resources or services offered by the Resource Owner (Alice) through a Resource Server that Alice controls. The Requesting Party (Bob) selects an ON (e.g. Node #1) to be the Client in the transaction, while the Resource Owner selects 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 to authenticate himself or herself. Hardjono Expires April 1, 2018 [Page 8] Internet-Draft Decentralized OAuth September 2017 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 method of node selection is outside the scope of this document and will be the subject of future specifications 2.6. Exclusivity of Services For simplicity of design, we propose the exclusive ownership of services at all ON nodes for any given time. Furthermore, the node operator must associate a public key with the service endpoint, independent of the current ownership of that service by the user. When a user (Resource Owner or Requesting Party) contracts a service offered by a node operator, that service is exclusively owned by (and under the full control of) the user throughout the duration of the contract. The node operator must not advertise otherwise, and potential users looking for services must verify (e.g. to a blockchain or contracts ledger) that a service point at a node is currently not under contract. The long-term binding of a public key with the service endpoint by the node operator across differing owners allow other users to validate the ownership-status of as given service, and also allows for cryptographic level binding for transport security (e.g. TLS). 3. Contracts Contracts form the basis for services acquisition and for data sharing. Services acquisition occurs between a user (Resource Owner or Requesting Party) and a node on the P2P network. Data sharing contracts occur between a Resource Owner and a Requesting Party, implemented through the services that each user contracts from ON operators. Contracts must contain legal prose that bind relevant parties and must contain indicators for dispute resolution. A contract may or may not contain executable code (i.e. smart contract). 3.1. 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 optionally code or Hardjono Expires April 1, 2018 [Page 9] Internet-Draft Decentralized OAuth September 2017 pseudocode that captures the computing functions involved in services acquisition or data sharing. The intent here is that users (Resource Owner or Requesting Party) would acquire services from nodes using bilateral contracts between the user and the node in an automated and semi-automated fashion, based on standardized templates of contracts. Similarly, within a data sharing transaction a Requesting Party would acquire access to data under the control of the Resource Owner by using a 3-party contract. In this case, the contract must identify the Client node (under control of the Requesting Party), the Authorization Server node and the Resource Server node (both under the control of the Resource Owner). 3.2. Types of Contracts We propose distinguishing two (2) types of contracts: o Service acquisition contract: A Service acquisition contract denotes the acquisition of specific OAuth2.0 services by a user (Resource Owner or Requesting Party) from a given OAuth2.0 Node operator. Service acquisition contracts are typically bilateral between a user and a OAuth2.0 Node operator. o Data Sharing contract: A data sharing contract denotes the granting of access by a Resource Owner to a data or resource to a Requesting Party using the services of the identified OAuth2.0 Node operator. Data sharing contracts typically involve up to five (5) entities: the Requesting Party, the Resource Owner, the operator of the Client ON, the operator of the Authorization Server ON and the operator of the Resource Server ON. A data sharing contract presumes that entities involved have acquired relevant services from ON node operators through bilateral service acquisition contracts 3.3. Service acquisition contracts: fields and parameters The following information is needed within a service acquisition contracts: o Type of contract o Identifier of the user (Requesting Party or Resource Owner) o Public key of the user o Identifier of the ON operator Hardjono Expires April 1, 2018 [Page 10] Internet-Draft Decentralized OAuth September 2017 o Public key of the ON operator o Public key of the service endpoint o Type of service provided (e.g. Client, RS, AS, OP, PS) 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 or pseudocode (optional) o Timestamp o Archive location of this contract (optional) o Contract template identifier and author (optional) o Target blockchain (optional) o Signature of User o Signature of ON operator 3.4. Data sharing contracts: fields and parameters The following information is needed within a data sharing contract: o Type of contract o Requesting Party: * Identifier of the Requesting Party * Public key of the Requesting Party o Client: * Identifier of the Client ON operator * Client service endpoints Hardjono Expires April 1, 2018 [Page 11] Internet-Draft Decentralized OAuth September 2017 * Public key of the Client ON operator * Public key of the Client service at the ON o Resource Owner: * Identifier of the Resource Owner * Public key of the Resource Owner o Resource Server: * Identifier of the Resource Server ON operator * RS service endpoints * Public key of the Resource Server ON operator * Public key of the RS service endpoint at the ON o Authorization Server: * Identifier of the Authorization Server ON operator * AS service endpoints * Public key of the Authorization Server ON operator * Public key of the AS service endpoint at the ON 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 terms and conditions o Code or pseudocode (optional) o Timestamp o Archive location of this contract (optional) Hardjono Expires April 1, 2018 [Page 12] Internet-Draft Decentralized OAuth September 2017 o Contract template identifier and author (optional) o Target blockchain (optional) o Signature of Requesting Party o Signature of Resource Owner data 4. Contracts and Blockchain Systems Blockchain technology offers interesting possibilities with regards to the notarization of contracts (for non-programmatic or "dumb" contracts) and with the regards to execution of code that may be embedded within programmatic contracts (smart contracts). In both cases, public key digital signatures represents a core function to provide source-authenticity of contracts. The proposed decentralized service architecture based on the peer-to- peer computing paradigm is independent from any given blockchain system, and independent of the permissions of blockchains (permissioned or public). In this context, we recognize two broad families of blockchains systems that are relevant to our transaction model or pattern: o Application-specific blockchain system (non-programmatic): The blockchain is designed to perform specific tasks which cannot be extended or modified. Examples include the Bitcoin blockchain system designed for a digital currency application. o Application-loadable blockchain system (programmatic): The blockchain support the notion of executable code running in one or more of the nodes of the blockchain, where the executable code can be programmed, loaded & offloaded, according to the intended application. The ledger function is integrated into the node, and as such records the results of the execution of the application. Such nodes may use virtual machine (VM) technology to achieve this effect. Examples include the Ethereum platform For the purposes of contract adherence and fulfilment, both families of blockchains systems can provide assistance to OAuth2.0 Nodes (ON) in fulfilling the transaction model stated above (resource sharing from Alice to Bob). The assistance available to nodes corresponds to the blockchain system type being: o Contract notarization and archiving: Entities who participate in service acquisition contracts or data sharing contracts can make use of a suitable non-programmatic blockchain system to keep a Hardjono Expires April 1, 2018 [Page 13] Internet-Draft Decentralized OAuth September 2017 (public) log of a signed contract. This can be done by storing a cryptographic hash of the contract within the transaction records of the ledger of the blockchain system. Systems such as the Bitcoin blockchain has some limited capacity to perform this function though the blockchain was not intended for use as a generic log for record keeping. o Data sharing flow execution and notarization: Nodes that have the capability to receive, load and execute code found in contracts may choose to run parts or all of the service function (Client- service AS-service, or RS-service) within its virtual machine space instead of the general compute space of the node hardware. o Dispute resolution: Disputes may occur even for completed and archived contracts. Blockchains offer the possibility of providing a common medium to capture evidence regarding a contract. The proposed decentralized service architecture does not require OAuth2.0 Node (ON) operators to implement the OAuth2.0 services in the form of executable code running in one or more of the nodes of the blockchain. 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 are discussed below. 5.1. Support for subset of services The proposed decentralized service architecture does not require OAuth2.0 Node (ON) operators to implement and make available all services. An operator is free to choose all or a subset of services. The method used for an ON to advertise available services is outside the scope of the current document. 5.2. Contracts expression language The current decentralized service architecture proposes the use of a JSON-based contract, which makes use the JOSE family cryptographic services for JSON (e.g. signing, encryption, key identification). See [JWS] and [JWE]. Hardjono Expires April 1, 2018 [Page 14] Internet-Draft Decentralized OAuth September 2017 Such a JSON-based contract will be the subject of a future specification. 5.3. 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 OAuth2.0 Node (ON) regardless of whether the node implements all the OAuth2.0 services or only a subset of these services. The contracts server function cannot be leased-out to users or other entities, and represents an operational infrastructure component for an ON. For a data sharing contract between a Requesting Party (employing a Client node) and the Resource Owner (employing an AS node), the contracts servers as the Client node and the AS node perform the relevant contracts-related tasks. Some of the core tasks of the contracts server on a node are as follows: o Locate and validate templates of standard contracts (optional) 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 (optional) o Deliver the executable-code (found in the agreed contract) to the relevant underlying blockchain-related component on the node (optional). Similar to endpoints in the UMA grant of OAuth2.0, the contracts server exposes a number of endpoints relevant to completing contracts agreement for service acquisition contracts and for data sharing contracts. The same endpoints should be used by callers for both service acquisition contracts and data sharing contracts. The type of Hardjono Expires April 1, 2018 [Page 15] Internet-Draft Decentralized OAuth September 2017 contract being presented by the caller must be clear from the type- of-contract field. 5.4. Contracts Access Token (CAT) A data sharing contract may come into existence as part of a Client's access attempt to a data/resource located at a Resource Server. When the Client is redirected to the AS in order to obtain an access token from the AS, the Client (and Requesting Party) may be required to complete a data sharing contract through a separate flow (sub-flow) with the contracts server. In this case, the default contracts server is that belonging to (underlying) the AS. The contracts server itself may be a protected resource, access to which requires a special access token from the AS. For ease of understanding, we refer to this token as the Contract Access Token (CAT). Note that the CAT is similar to the PAT token in the UMA context. The Client must first obtain a CAT from the AS prior to engaging the contracts server. After obtaining a CAT from the AS, the Client (or more correctly the Client's own contracts server) presents the CAT to the contracts server at the AS together with a proposed contract or contract template identifier. The contracts server at the AS validates both the CAT and the proposed contract (or template), completes the necessary fields (e.g. the RS location, endpoint and public key), signs it and returns it to the Client. The Client must validate the received contract, counter- signs it and returns it to the contracts server at the AS. After the contracts server at the AS validate the integrity and signature of the contract, it may optionally record it on the blockchain or distributed ledger. The AS then issues the Client with the relevant access token (per UMA2.0 flows) to present to the RS. The access token specifies the resources available to the Client and Requesting Party following the agreed contract. It may optionally include pointers to the contract, meaningful only to the AS (i.e. in the case of token validation). 5.5. Blockchain Client The Blockchain Client (BC) is a new functional capability introduced into this architecture that did not previously exist in the OAuth2.0, OIDC1.0 or UMA2.0 designs. Hardjono Expires April 1, 2018 [Page 16] Internet-Draft Decentralized OAuth September 2017 The blockchain client interacts with the relevant underlying blockchain systems or distributed ledger system shared between the Requesting Party and the Resource Owner. The blockchain client is used by the contract server within an OAuth2.0 Node to transmit blockchain-transaction to the target blockchain system. It is also used by the node to validate the existence of a given previous transaction on the blockchain. The blockchain client may also be used for payments related to service acquisition contracts (e.g. between a user and an ON operator) and to data sharing contracts (e.g. Requesting Party paying Resource Owners). 5.6. Contracts Access Token (CAT) The current decentralized service architecture proposes the use of a JSON-based contract, which makes use the JOSE family cryptographic services for JSON (e.g. signing, encryption, key identification). Such a JSON-based contract will be the subject of a future specification. 5.7. Public keys and binding to contracts Public key cryptography plays an important role in contracts due to its ability to provide technical-trust (through proof-of-possession and strength of the chosen public-key cryptosystem) and to provide legal-trust through the legal acceptance of digital-signatures as legal signatures (i.e. Digital Signature Act). Node operators must possess the following public key pairs in order to support the proposed decentralized model: o Operator-level public key: A node operator must possess an operator level public key that it uses to legally sign contracts. This public key must be long-term and be legally associated/owned by the operator (e.g. through a CA-issued certificate). o Service endpoint public keys: For each OAuth2.0 service supported, the node operator must associate and bind a unique long-term public key to that service Public key pairs are used in this architecture for the following: o Contracts signing: the public-key pair is used to digitally signed a contract by entities involved in a service acquisition contract or data sharing contract. Hardjono Expires April 1, 2018 [Page 17] Internet-Draft Decentralized OAuth September 2017 o Service endpoint authentication: the public-key pair is used to authenticate a service end-point and to cryptographically bind the secure channel to the session between the caller and the service end-point (e.g. see RFC5929 and RFC5056) o Access to blockchain: the public-key pair of a service endpoint can used to submit a transaction to a blockchain or distributed ledger system, where the system accepts the transaction as source- authenticated. o Contracts execution (smart contracts): the public-key pair is used by the a blockchain or distributed ledger system to execute the code (e.g. bytecode) found within a contract and where the public- key is invoked by the executing code 5.8. End of Contract Actions At the end of a contract period, an OAuth2.0 Node (ON) must perform post-contract action as specified in the contract (service acquisition contract and data sharing contract). These post-contract action may or may not be recorded in some manner through a blockchain to provide evidence of its own completion. Examples of end-of-contract actions include transferring data to another repository (e.g. to another RS), flushing all user data cached at the node, claiming payments (e.g. at a payments escrow party), and so on. The end-of-contract actions will be the subject t of a future specification. 6. IANA Considerations TBD. 7. Security Considerations This document pertains to a peer-to-peer infrastructure for data sharing based on digital contracts. 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: Hardjono Expires April 1, 2018 [Page 18] Internet-Draft Decentralized OAuth September 2017 Proof of correct execution: One of the security challenges involves obtaining evidence that a node has not deviated from the agreed 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 service acquisition contracts and data sharing contracts), there is the question of the correct service semantics being captured in the contract, both in the legal prose and within executable code (or pseudocode). 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 The following people made significant contributions to the contents of this document: o Christian Smith (MIT) o Dmitri Zagidulin (MIT) o Greg Linklater (Rhodes University) Hardjono Expires April 1, 2018 [Page 19] Internet-Draft Decentralized OAuth September 2017 o Eve Maler (ForgeRock) 10. References 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, . Hardjono Expires April 1, 2018 [Page 20] Internet-Draft Decentralized OAuth September 2017 10.2. Informative References [Bitcoin] Nakamoto, S., "Bitcoin: a Peer to Peer Electronic Cash system", 2008, . [Corda] Brown, R., Carlyle, J., Grigg, I., and M. Hearn, "Corda: An Introduction", August 2016, . [Eth] "Ethereum.org", . [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, . Author's Address Thomas Hardjono MIT Email: hardjono@mit.edu Hardjono Expires April 1, 2018 [Page 21]