Re: Identity Hub Concept

Michael Herman (Web 7.0)

I highly recommend the Microsoft “Trinity” Graph Engine and the Trinity Specification Language (TSL) for designing entire systems based on credentials, messages, HTTP and non-HTTP protocols, and automatic code generated repositories, agents, and agent service endpoints.


Check out


Pure (credential) storage example:


Pure agent, agent service endpoint, protocol, message  example:


Have fun,



Best regards,

Michael Herman

Far Left Self-Sovereignist


Self-Sovereign Blockchain Architect

Trusted Digital Web

Hyperonomy Digital Identity Lab

Parallelspace Corporation





From: sds-wg@... <sds-wg@...> On Behalf Of Adrian Gropper
Sent: July 21, 2021 8:30 PM
Subject: [sds-wg] Identity Hub Concept


I've been mostly lurking on the Hub discussions trying to imagine how I would implement a DID service endpoint that was interoperable across a broad range of apps..


Put another way, if I was building a microservice app and needed to personalize it based on a subject's DID, what would I want beyond the features already offered by CouchDB for the persistence component.


IH1 - The subject's DID would de-reference to a service endpoint of type Identity Hub. To avoid confusion and excess exposure, the DID should have only one service endpoint. (Here's a very long thread (of many) where you can draw your own conclusions if you disagree but try to stay with me for the rest of my argument.) The main benefit of this first step is that the subject can change the service endpoint without changing the DID itself. If correlation is an issue for the subject they can add an optional mediator to the (one) service endpoint.

IH2 - Given IH1, as an app developer, I would want to be able to make a request to that service endpoint based only on having some DID. The request should be an interoperable object such as OAuth RAR that makes no assumptions about the domain or functionality of my app 


IH3 - In the general case, the next step would be some kind of discovery. The request object should have 

  • a type that is likely specific to the domain of the app (health, education, travel), 
  • a scope,
  • a purpose, and
  • some credentials to convince the service endpoint that it wants to respond

IH4 - The response would provide an access token and/with a pointer to a directory. The app could query the directory as constrained by the token.


IH5 - The result of IH4 might provide the app with service endpoints to resource servers and metadata to help the app decide which ones were worth trying to access.


IH6 - The app might already have sufficient capability in the IH4 token or it would need to negotiate updated requests with the Identity Hub service endpoint.


IH7 - The microservice app interacts as a client to the resource. 


Very Important: Note that the end-user of the app may or may not be the subject of the DID.


What's missing?


- Adrian



Join to automatically receive all group messages.