The Respect Network Technical and Operational Specifications Version 1.0

(1)

The Respect Network

Technical and Operational

Specifications

Version 1.0

V1—2014-‐06-‐23

Abstract

This subdocument of the Respect Trust Framework™ defines the technical and operational rules of the Respect Trust Framework. Note: this version defines the rules that apply to Cloud Service Providers (CSPs). Future versions will define the rules that apply to application developers.

Purpose

The Respect Network is a global private network for individual members and

business members. Respect Network Corporation has developed the legal, business and technical infrastructure (software) and maintains specifications required to operate the network.

Cloud Service Providers (CSPs) provide the member interface to the network. The network is premised on business, legal and technical interoperability required to provide secure communications channels, personal data management and

application functionality between members in a context of respect for individual privacy and control over personal data.

For a more detailed introduction, see the main Respect Trust Framework.

For a definition of frequently used terms and acronyms, see the Glossary below.

Scope

This specification is a subdocument of the Respect Trust Framework Version 2. It contains normative specifications for Respect Network members using MUST, SHOULD and SHOULD NOT keywords, which should be interpreted as described in [RFC 2119].

CSPs MUST self-‐assess against these specifications initially; processes for

community review, third party assessment or certification may be established in the future. For more information on future plans see Section 5 Future Looking

Statements.

CSPs MUST comply with all MUST requirements within 60 days of the date on this specification unless otherwise stated herein. CSPs MUST comply with the majority of the SHOULD requirements within 90 days, except in cases where there is strong technical or security justification to not comply with a SHOULD requirement.

Implementation Scenarios

(4)

Figure 1: Respect Network Software Modules and Services for CSPs Note: Based on http://docs.respectnetwork.net/wiki/Platform_Architecture

Configurations

The Respect Network Corporation will provide CSPs with software implementations of all the front end and back end service modules shown in Figure 1.

A CSP may choose one of four configurations based on this software or customer software the CSP develops, to provide services as described below. The

configuration selected has a material impact on how elements of this Technical and Operations Specification apply to the CSP.

Each CSP is responsible for ensuring proper compliance as described in their Configuration level as well as all lower-‐numbered Configuration levels. So, for example, a CSP in running in Configuration 2 must implement Configuration 2 and Configuration 1 but is not required to implement Configuration 3 or Configuration 4. However, the CSP retains legal ownership of the service and responsibility to

Respect Network members. The CSP MUST ensure that their outsourced providers (“contractors”) comply with all requirements delegated to those providers such that -‐ between the CSP and the providers – they comply with the complete Technical and

(5)

Operation Specifications specified in Configurations 1 through 3 (and Configuration 4 if applicable).

Also, to the extent the CSP maintains personal data and services for Respect Network members outside of the personal cloud (e.g billing systems, mailing lists and others) the CSP MUST maintain equivalent protections for them (per Section 1.1.3) to fulfill their obligations under the Respect Trust Framework.

Configuration 1: Fully Outsourced

In the fully outsourced configuration, a CSPs has outsourced the entirety of personal cloud hosting and all personal-‐cloud related administrative functions (including all manually-‐implemented processes for portability, key management, support and other functions) to another provider.

Configuration 2: CSP-‐Hosted Front End

In the CSP-‐Hosted front end configuration, the Back End hosting is outsourced to a provider.

Configuration 3: CSP-‐Hosted Stock Back End Server

In the CSP-‐Hosted Stock Back End, the CSP is hosting and managing the entire Front End and Back End technical infrastructure using the then current release of the Project Danube XDI2 server software.

Configuration 4: CSP-‐Hosted Custom Back End

In the CSP-‐Hosted Custom Back End configuration, the CSP is hosting and managing the entire technical infrastructure and has modified the Project Danube XDI2 server software.

Configuration 1

Configuration 1 CSPs are responsible for implementing the requirements in Section 1, and for ensuring their outsource suppliers comply with Sections 2, 3 and 4.

1.1.Security & Privacy Requirements

This section provides requirements for CSPs and outsourced contractors running in this configuration regarding general security robustness.

1.1.1 Administrative Access to Personal Data

Starting immediately:

• CSPs MUST implement documented administrator-‐level access control,

separation of duty and audit/accountability policies, procedures and technologies.

(6)

• CSPs MUST log all administrator access to personal data and MUST

provide mechanisms or procedures to protect the integrity of the audit logs.

• CSPs MUST disclose

o Any administrative access made to personal clouds outside of policy (unless legally prohibited from doing so according to the laws of their jurisdiction).

o Any administrative access to their personal clouds made

according to policy.

• CSPs MUST require two-‐factor authentication for administrators.

CSPs MUST disclose to members:

• The levels and means of access CSP administrators have to the personal

cloud and the policies governing such access. Note that as of the June release (before the deployment of Respect Network secure file storage technology) the persistent storage layer (currently using Mongo DB) is accessible to CSP administrators running the Graph Service.

• Their general legal interpretation of obligations to the jurisdictional

authority

o Policy on responding to governmental requests within

jurisdictional due process (e.g. court order) for information targeted at an individual user, or small number of users

o Policy on responding to governmental requests outside of due

process for information targeted at an individual user, or small number of users

o Policy on responding to governmental requests for bulk

information about many users

1.1.2 Legal Jurisdiction and Notification

The CSP MUST disclose to members the national jurisdiction(s) where their data will be stored.

CSPs MUST implement regulatory compliance and breach disclosure according to the legal requirements of their jurisdiction..

CSPs SHOULD resist through the legal processes available in their jurisdiction any governmental requests for bulk information targeted at many users. CSPs SHOULD set aside funds for their legal defense against bulk information requests.

(7)

CSPs SHOULD perform transparency reporting (aka “warrant canaries”) wherein regular reports on the absence of governmental bulk data and/or targeted data requests are routinely issued unless and until such requests are received. Such reporting may be a way to partially circumvent “gag orders” that accompany some governmental data requests. When adopting

transparency reporting, CSPs MUST consult legal counsel qualified in the applicable operating jurisdictions.

1.1.3 Meet General Security and Operational Requirements

CSPs MUST develop security governance processes, including a Security Plan and Security Policy covering people, process and technology for both their internal operations and any outsource partner supply chain partners.

CSPs SHOULD use ISO 27000 series, or a similar standards framework as their basis for security governance. CSPs MUST assess their operations against their stated security policies, track exceptions and incidents, and remediate

exceptions and incidents.

CSPs SHOULD engage third party auditors or other objective experts to assist their assessment.

If the CSP maintains personal data and services for Respect Network members outside of the personal cloud (e.g billing systems, mailing lists) it and/or other outsourcers employed for those functions MUST also support the protections specified in this Section 1.1 and in Sections 2.1.4, 2.1.5, 2.1.6, 2.1.7 and 2.1.8; however, if an outsourcer is industry-‐certified (e.g. through Payment Card Industry Data Security Standards certification in good standing) to provide personal data protection through alternate methods, some of those

requirements may be waived. If the CSP and/or other outsourcers maintain accounts for members to access any personal information outside the personal cloud, they must support authentication mechanisms at least as robust as specified in Section 2.1.1 and 2.1.2.

CSPs and contractors MUST NOT store databases, spreadsheet files or other lists containing members’ personal information on endpoint (client) devices used by their employees or contractors unless strong compensating controls are applied. Examples of compensating controls may include filtering the data, masking the data, encrypting the data and/or purging it shortly after use. In the event of a breach, any such compensating controls shall be deemed to have been inadequate.

“Personal information” is defined to include any data that could be used to distinguish or trace a person’s identity that comes into the CSP’s possession

(8)

(e.g. but not limited to cloud names, cloud numbers, email addresses, phone numbers, credit card numbers, IP addresses); other data that is legally

protected in the CSP or the members’ jurisdiction as such; and any information that the member stores in the personal cloud, might reasonably consider private and has not released from privacy obligations under the service's terms and conditions or other valid opt-‐in process.

CSPs and contractors MUST provide employees and contractors with clear policies and training on the protection of member data from social engineering attacks, on the protection of the endpoint (client) devices they use and in the fulfillment of other security-‐related roles and responsibilities.

Configuration 2

Configuration 2 CSPs are required to implement the requirements in Sections 1 and 2. They are also responsible for ensuring their outsource suppliers comply with sections 3 and 4.

This section provides requirements for CSPs running in this configuration regarding general security robustness.

4.1.1. Authenticate Persons to their Personal or Business Clouds

Respect Network partners include companies providing advanced

authentication solutions. CSPs may implement solutions that are stronger than password-‐based login, and Respect Network intends to extend more

authentication options in the future. See the Section 5 for more information. Using the Authorization Manager Service, CSPs MUST meet the following minimum requirements for password login.

• Online login for the user must meet the following requirements

o Any traffic communicated in the context of an authenticated

session MUST be protected by HTTPS. SSL 3 and TLS 1.0 SHOULD NOT be used.

o Inactive local user authenticated sessions MUST be re-‐

authenticated after a configurable or defined interval.

o Sensitive user profile management actions such as password

changes SHOULD NOT be available based on single sign on (SSO) sessions and MUST require explicit re-‐authentication.

o Stored user passwords MUST be stored salted and hashed by a

(9)

cryptographic mechanisms. MD5 and SHA-‐1 SHOULD NOT be used.

• All passwords MUST adhere at least to the “basic password”

specification. CSPs may furnish password strength and other

authentication metadata in authentication flows to enable higher levels of assurance (LOAs) for relying parties.

o Basic password: Must be at least 6 characters and contain at

least one letter and one number. They should only be

implemented in tandem with account lockout procedures (see below).

o Medium Password: Must be at least 8 characters, have at least 1

letter, 1 number and at least one special character, e.g. @, #, $ etc.

o Strong Password: Must be at least 10 characters and have at

least 1 upper case letter, 1 lower case letter, at least one number and at least one special character, e.g. @, #, $ etc. New password cannot be the same as the previous three. CSPs must

recommend password change every 180 days."

• CSPs MUST mitigate against "brute force" attacks on the login process,

such as password and/or username guessing. Acceptable methods include either:

o Use MEDIUM or STRONG password policies.

o Or, support account lockout for a period of minutes after 3-‐5

failed login attempts and initiate “robust account recovery” after 5-‐10 attempts. Alternatively, support account lockout based on varying parameters using a security analytics system

(sometimes termed passive authentication, or risk-‐based authentication). CSPs performing account lockout SHOULD mitigate the risk of it being used against them in denial of service attacks on a single user or their entire service.

• CSPs SHOULD mitigate against the risk of malware obtaining user

passwords and logging in from a remote device. Acceptable methods include:

o Use a two factor authentication code with a factor that is

unlikely to be obtained through automated cyberattacks (e.g. SMS message to a secondary user device).

o Support account lockout based on a security analytics system or

(10)

4.1.2. Robust Account Recovery

For password recovery after a lost password, or account lockout, CSPs MUST perform identity verification. One acceptable identify verification method is dual email and SMS code verification.

4.1.3. Support Coordinated Security and Operations

The following functions are required for CSPs in this configuration to enable data portability and to coordinate security and operations with other services on the Respect Network. Immediately following the June launch many of these functions may be provided manually with automation to be added at the earliest opportunity.

• Security Data Sharing: CSPs MUST implement regulatory compliance

and breach disclosure according to the legal requirements of their jurisdiction and their customers’ jurisdictions. CSPs SHOULD also share threat indicators and other data from cyber-‐attacks they experience that could reasonably be expected to affect other Respect Network CSPs and members.

• Vulnerability reporting: CSPs utilizing the Personal Cloud Stack MUST

notify the community of any vulnerabilities or bugs they locate.

4.1.4. Application layer security

CSPs SHOULD document self-‐developed code and system architecture.

CSPs SHOULD implement versioning, change and configuration control, change monitoring, rollback and staging of releases across development, testing and production areas.

CSPs MUST utilize a methodology incorporating security into their software development life cycle (SDLC), including risk assessment, threat modeling and static code analysis against any self-‐developed code and the overall system. CSPs MUST require contractors or suppliers of code to also incorporate security into their SDLC.

CSPs SHOULD conduct security reviews of and security testing against their APIs.

CSPs SHOULD provide dynamic security testing, web application firewall (WAF) protection, application monitoring, and API security and monitoring. CSPs SHOULD assess and/or test Javascript (and other browser-‐based code that crosses the trust boundary between network services and client-‐side

(11)

devices) for cross site scripting, code injection and other applicable OWASP vulnerabilities.

4.1.5. Administrative Identity and Access Management

CSPs MUST implement two factor authentication for their developer and administrator accounts. CSPs SHOULD implement role management, automated account de-‐provisioning, separation of duty and audit for administrative functions over internal development and operations.

CSPs SHOULD implement robust internal processes for managing all system and service accounts and credentials (e.g. account naming standards, regular credential changes, token database encryption / protection).

4.1.6. Endpoint security

CSPs MUST implement password protection and software security updates for all physical or virtual servers, and all client devices used by development and operations staff to host or access members’ personal information.

CSPs MUST also implement anti-‐malware scanning and system firewalls for all Windows-‐based servers and client devices and SHOULD implement same for most other OSes (e.g. Linux, Android, Apple OSX).

CSPs SHOULD impart personal cloud users with knowledge of the above guidance and other security awareness through optional documentation or coaching.

4.1.7. Network layer security

CSPs MUST deploy, use or contract for network and/or host server-‐based firewalls to protect physical or virtual servers. All firewalls SHOULD be centrally managed to receive regular threat feeds and configuration updates. CSPs MUST implement or use secure communication channels (e.g. SSH, IPSEC or SSL VPN) for administration of physical or virtual servers. Two factor authentication MUST be provided for all such remote access.

CSPs SHOULD deploy, use or contract for network intrusion detection (IDS), DDOS protection, load balancers, CDNs , etc. to protect the confidentiality, integrity and availability of the services.

4.1.8. Logical and Physical Data Center Security

Compute and storage resources used to host the running instances of Front End Software MUST be protected with physical data center and server

(12)

security, virtual server security and access controls, vulnerability and patch management, change monitoring, backups etc. at all logical and physical layers.

4.1.9. Security monitoring

Security logs and events MUST be collected and regularly reviewed on

administrative actions, security-‐related events and the operation and activity of security tools and infrastructure components.

Security analytics SHOULD be used to monitor multiple logs and other security-‐related data or event sources. Where used, security and other analytics MUST NOT create persistent stores or tracking of non-‐anonymized personal data except as stated in the CSP's terms of service or privacy policies.

4.2.Front End Software Requirements 4.1.1. Basic Functional Requirements

The following functional flows MUST be supported within 90 days of release to staging:

• A Member may obtain additional Cloud Names

• A person signing up may select more than one Cloud Name

• A Member may transfer their Cloud Name from one CSP to another • A Member may register Discovery Keys

• A Member may change their Cloud Name

• A Member may choose to leave the Respect Network

• Registration will be enhanced to include short holds on Cloud Names to

prevent someone else from obtaining it during payment process.

• A Member may Register a Personal Cloud • A Member may Register a Business Cloud • Service and Key Discovery

• Member sets up XDI Link Contracts for Access Control • Member reviews permissions granted to connections • Member reviews connections to their Personal Cloud • Key Management in Primary Cloud

• Interact with another Peer Cloud

• Interact with an external Service from a Personal Cloud • Interact with a Personal Cloud from an external Service • Move Primary Personal Cloud from one CSP to another • Unregister Primary Personal Cloud

(13)

4.2.Policy & Operations 4.2.1. Business Continuity

CSPs MUST perform regular backups of the system components required to maintain service availability and security.

CSPs SHOULD provide failover facilities as well as operational procedures and plans to recover from foreseeable power, network, system, storage and other component outages.

4.2.2. Service Level Agreements

CSP hereby guarantees that its critical server and network infrastructure, their availability, and any other CSP Services, whether provided to RNC or to other Members, will meet or exceed all industry standards for cloud service

providers operating within the local area in which the CSP operates. CSPs SHOULD publish an SLA for customers documenting

• Basic levels of availability (e.g. 99.99%)

• Business continuity provisions (e.g. cold stand by, lazy replication) • Support process (e.g. help desk hours and expected wait times)

Configuration 3

Configuration 3 CSPs are responsible for implementing the requirements in Sections 1, 2, and 3. They are also responsible for ensuring their outsource suppliers comply with Section 4.

4.1.1. Support Personal Cloud Credential Management and Portability

The following functions are required for CSPs in this configuration to enable data portability and to coordinate security and operations with other services on the Respect Network. Immediately following the June launch many of these functions may be provided manually with automation to be added at the earliest opportunity.

• Peer cloud key management: CSPs MUST support mechanisms for

key creation, replacement, removal and archival.

• Peer cloud lockout: CSPs MUST support both temporary peer cloud

"account lockout" and disabling of its keys in the event of a security or privacy-‐related incident, such as a reported or detected compromise of

(14)

the credentials or suspension/revocation of the member's right to operate on Respect Network.

• Peer cloud backup and export:

o CSPs MUST provide regular backup of personal cloud data for business continuity.

o Upon the owner's request, CSPs MUST provide the ability to export a peer cloud's XDI graph in XDI Javascript Object Notation (JSON) serialization format and all files of personal or business data in their native format for download

• Peer cloud restore and import:CSPs MUST provide the inverse of

"peer cloud offline backup and data export" so as to be able to accept existing peer cloud data moving to their service from another Respect Network CSP. CSPs MUST also provide this function to enable full or partial restore of the XDI graph or other personal data upon the owner's request.

• Cancellation of Service: CSPs MUST enable a peer cloud owner to

cancel membership, export and then permanently delete the data. CSPs MUST offer unsubscribing persons or businesses the choice of moving to another CSP or permanently leaving the Respect Network. For users permanently leaving the Respect Network, CSPs MUST remove their cloud names, numbers and discovery keys from the Registry and SHOULD remove other data from the personal cloud upon the member’s request.

• Cancellation of connections or permissions: The CSP Connection

Manager MUST enable peer cloud owners to cancel one or more of their connections. CSPs SHOULD enable peer cloud owners to cancel any optional permissions associated with a connection without cancelling the entire connection. CSPs receiving requests to cancel connections or permissions MUST delete local copies or caches of the data. For

connections or permissions whose ongoing maintenance are necessary to the maintenance of a contracted service CSPs MAY take other actions as specified in their Terms of Service or Privacy Policy.

4.1.2. Logical and physical data center security

Compute and storage resources used to host the running instances of Back End Software and personal clouds MUST be protected with physical data center and server security, virtual server security and access controls, vulnerability and patch management, change monitoring, backups etc. at all logical and physical layers.

(15)

4.2.Back End Software Requirements

CSP key management: CSPs MUST provide key management and protection over the keys to their own peer cloud at least as strong as those provided to protect their customers. As with peer cloud public key material, CSPs’ public keys will be stored in their CSP XDI graph and the corresponding private keys used to sign XDI messages.

Configuration 4

Configuration 4 CSPs are responsible for implementing the requirements in Section 1, 2, 3 and 4.

4.1.Back End Software Requirements

4.1.1. Generate XDI Messages Between CSP, Peer Clouds and RN Services

All Respect Network flows between peer clouds in the network MUST be conducted via XDI Messages as specified by the OASIS XDI Technical

Committee (XDI TC). CSPs MAY use arbitrary protocols for flows between their front end services and their individual or business customers and for services not related to Respect Network (such as internal flows or flows between the CSP’s service and external sites, such as Flickr.)

4.1.2. Application Program Interfaces (APIs) for XDI Messaging

The Respect Network and Project Danube-‐provided software modules include application program interfaces (APIs) for CSPs to construct common flows using XDI messages. XDI message contents MUST be delivered via HTTPS Post operations to XDI endpoints denoted by cloud addresses, or URIs, of the peer clouds. For example, the request to register a new member has a message with an envelope containing mandatory and optional statements (i.e. lines in a message). All XDI messages between peer cloud XDI servers MUST be posted using HTTPS (for transport confidentiality and integrity) and signed with XDI signatures (for message integrity and origin authentication). Maintain Open and Interoperable Semantic Data Representations for Personal Clouds In order to assure portability and interoperability in the Respect Network, CSPs MUST be able to represent the peer clouds they host as XDI graphs and conduct XDI GET, SET, and other operations against the graphs as required to accomplish the flows usingXDI messages.

(16)

4.1.3. Maintain “User Graph” XDI Representation of Personal Clouds

CSPs MUST support representation of the user’s personal cloud as an XDI graph called the “User Graph”, which is specified in the Member Graph Working Doc.

4.1.4. Maintain “CSP Graph” XDI Representation

A form of a business graph that represents the CSP, itself a business on the Respect Network. contains the CSP's 'customer records'. Is also specified in the Member Graph Working Doc.

4.1.5. Require Only Indirect Access to the Respect Network Member Graph

CSPs indirectly read and write the Respect Network Member graph (which contains the minimal required naming, addressing and other information necessary to maintain the network.) All such access is through the service APIs for the Registration Service, Discovery Service and Reputation Service.

4.1.6. Control and Audit Access to Personal Clouds Using Link Contracts

CSPs MUST provide an Authorization Manager Service to evaluate and/or decline requests for access from peer clouds using XDI Link Contracts and XDI Policy Expressions as specified by the OASIS TC.

4.1.7. Meet Data Protection and Cryptographic requirements

CSPs SHOULD provide disk or file level encryption for the XDI graph and all other personal cloud data.

CSPs MUST provide the following key management functions:

• Generate public/private key pairs for signing and encrypting XDI

message. CSPs MUST store the public keys in the user’s graph and SHOULD support HSM storage of the private key(s).

• Support key change through their front-‐end interfaces and through

administrative interfaces if either the member or the CSP believes a key has been compromised.

Future

Work

This section identifies known areas to expect new requirements in the future. Additional future plans will be published as they develop.

(17)

4.1.Privacy and Security Requirements 4.1.1. Robust Account Recovery

Other acceptable identity verification methods (in addition to those described in Section 2.1.1 and 2.1.2) may be provided by Identity Verification Partners in the future

4.1.2. Certification and Assessment

Requirements for reporting on the self-‐assessment, or for third party

assessments or certifications may be determined by the partners in the future.

4.1.3. Support Coordinated Security & Operations

Manage multiple peer clouds for a single owner: CSPs SHOULD enable a member to register or unregister/unsubscribe multiple peer cloud instances under its singular identity, or reputation, within a single or multiple CSPs.

4.2.Front End and Back End Software Requirements

4.2.1. Maintain “Business Graph” XDI Representation of Business Clouds

CSPs MUST support the ability for business members to be represented using an XDI organization graph which contains the business name and any other information particular to that business and that identifies the user graphs of the persons representing that business.

4.2.2. CSP to Personal Cloud Session Management Requirements

CSP-‐provided applications and services MUST support Respect Network’s Single Logout Profile (TBD). Through this specification, when a user logs out of the personal cloud (or times out through inactivity), the CSP MUST notify any Respect Network applications to which the user has authenticated (using the Connect Service) to log out any local sessions (e.g. HTTP) they maintain for the user.

4.2.3. Authorization Manager and Connection Manager UI Service

The Authorization Manager Service and the Connection Manager UI Service MUST support the following additional requirements:

• Maintain base cloud portability for connections, relationships and

permissions specified in link contracts.

• Display clear UI messages for the user as to the nature of the

permissions granted to the opposite party (e.g. “use but don’t save my credit card number or mobile phone number”).

(18)

• Maintain an audit trail of link contract creation, deletion or changes as

well as of access to personal data controlled by link contracts.

4.2.4. Advanced Authentication Plans

CSPs SHOULD (or MUST) offer members two factor authentication options and SHOULD offer extensible or federated identity authentication and levels of assurance support. For more information, see theRespect Network T&O Specifications: Informational Notes working document.

4.2.5. Secure File Storage and Data Exchange

Respect Network plans to provide for secure file storage and secure data exchange in 2014 timeframe for all members. These requirements will be released in an upcoming version of this specification and will enable encryption of files, folders and data on the wire using encryption keys

controlled by the member and not accessible even to the CSP’s administrators.

4.2.6. Signed XDI Message Specification Support

Configuration 4 requirements for signed XDI message formats will be specified in the Respect Network profiles of the corresponding XDI Signatures, XDI Cryptographic Syntaxes and/or XDI Security Mechanisms specifications. These specifications will cover not only the message signing formats, but also the requirement to limit caching of public keys used to verify signatures to less than 15 minutes, or some other short period to be specified. An update to this specification will incorporate these requirements once they can be presented in detail.

Glossary

Business Graph: The XDI Graph that may contain identity, security, Discovery, Identification, Link Contracts, user data, discovery and encryption keys, member profile and services for a Business Member. The Business Graph is typically stored by the CSP but may be hosted elsewhere.

Discovery: The process of locating a Cloud Name and associated Cloud Number on the Respect Network.

Link Contract: A mix of human and machine-‐readable policy that governs the access and distribution of data. A link contract is a binding agreement between parties in the Respect Network systems of accountability.

Member Graph: The Member Graph is an XDI Graph that may contain identity, security, Discovery, Identification, Link Contracts, user data, discovery and

(19)

encryption keys, member profile and services for an Member who is not a business. The Member Graph is typically stored by the CSP but may be hosted elsewhere.

Personal Cloud: The equivalent of personal computer except operating “in the cloud”, i.e., not on a physical device you carry. A Personal Cloud stores information that can be accessed by the Member who owns the Personal Cloud. Specific sections of a Personal Cloud can be shared with other Members. By default, the Personal Cloud is hosted at the Member’s CSP but a Personal Cloud can be hosted anywhere.

Respect Network Application: A program written by a developer working for a company that has agreed to the Respect Trust Framework. This application takes on the identity and reputation of that company and its administrator accounts.

Respect Network Infrastructure Services: Currently comprise the registration, discovery, connect and reputation service. Dictionary, signaling and billing services planned.

XDI Graph: All XDI data conceptually belongs to a global graph in which it can be addressed through uniform resource identifiers (URIs) and to a local graph

controlled by an administrative authority. A personal cloud is an example of an XDI graph.

XDI Message: An XDI graph sent between two or more XDI endpoints to perform semantic data interchange.

Copyrights and Trademarks

Respect Network™, Respect Trust Framework™, Respect Reputation System™, Respect Credits™, and The Respect Promise™ are trademarks of Respect Network Corporation.

Respect Network Corporation

The Respect Network Technical and Operational Specifications Version 1.0