Getting Started
- Quickstart
- How to use Hyperties in Applications
- How to develop new Hyperties
- How to develop new Protostubs
- How to develop new Idp Proxies
- Interworking Protostubs for Chat
- Interworking Protostubs for WebRTC
- How to develop Message Nodes
- reTHINK Core Framework implementation
Concepts
- Conceptual Foundations
- Hyper-linked Entities - Hyperties
- Decentralized Messaging
- Protocol on-the-fly
- P2P Data Synchronization
- Decentralized Trust
- Reference Architecture
- Communication Control Main Workflows
APIs
Messaging Framework
- Messaging Framework Overview
- Messaging Node
- Protostub specification
- P2P Message Delivery
- Message Node and Protostubs design recommendations
Runtime
Trust Management
How it Works - Basics
- Overview on reTHINK Basic Mechanisms
- Runtime Deployment
- Hyperty Deployment
- Protocol Stub Deployment
- Address Allocation
- Hyperty Registration
- Message Routing
- Routing Address Resolve for Msg Node Stubs
- Routing Address Resolve
- Intra-runtime Msg Delivery
- Inter-runtime Msg delivery
- Cross Domain Msg delivery
- P2P Msg delivery
How it Works - Data Synchronization
- P2P Data Sync Overview
- Data Object Creation
- Data Object Subscription
- Data Object Unsubscription
- Data Object Delete
- Data Object Child
- Data Sync Resume for Observers
- Data Sync Resume for Reporters
- Observer unsubscribed by Reporter
- Data Object Reporter Delegation
How it Works - Discovery
How it Works - Identity Management
- Identity Management Overview
- Identity Binding
- Id Token generation
- User identity assertion
- Domain Login
How it Works - Legacy Interworking
Testing
- Tests and Evaluation Overview
- Interoperability Evaluation
- Identity Management Evaluation
- Message Node Evaluation
Core Datamodel
Data Object Models
- Communication Data Object
- Connection Data Object
- Context Data Object
- Databackup Data Object
- Wallet Data Object
- E-commerce Data Object
- Spot Data Object
- Device Data Object
- Elearning Data Object
Messages Specification
- Messages Specification Overview
- Data Object Synchronization
- Address Allocation
- Registration
- Wallet management
- Discovery
- Identity Management
- P2P Connections Management
Backend Deployment
Standards
Use-Cases
- reTHINK Use Cases Overview
- H2H Conversation with single CSP
- H2H inter-domain Manageable Conversation
- H2H Conversation with decoupled CSP and IdP
- Always Connected with the Trusful Ones
- Dynamic Media Server or Media Gateway provisioning
- Trust
- H2H Conversation with QoS
- H2H Partial Anonymous Conversation
- H2H Multiparty Conversations
- H2H Conversation Browsing
- User Authentication and Registration
- Service Subscription
- M2M Seamless connected from different but Trustful domains
- Validation of trust
- M2M Always Connected in Trustful Domains for Multi vendor devices
- Human Context Presence Management
- Service Recommendation by Business Broker
H2H Conversation with decoupled CSP and IdP
Actors
Alice is Identified Consumer that is a Conversation Participant
Bob is Identified Consumer that is a Conversation Participant
Alice and Bob are subscribers of the same Communication Service Provider but each one use identities managed by different Identity Service Providers
Pre-conditions:
- #83 Alice and Bob are registered in the same CSP using external identities provided by different IdPs. It would also be possible to have one of the peers using “native” identifiers from the CSP and the other peer using external identifiers .
- Alice knows Bob identifier, which is provided by an external IdP
- remark: The following needs to be defined in a use case within the identity domain!!!! Each participant is certified about the identity of remote participants by using assertions managed by an external Identity Service Provider.
Description
Similar to H2H Conversation with single CSP.
Differentiation – market relevance
Market relevant but not currently available.
#3 H2H Communication UC and Identity Management