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 https://www.graphengine.io/
Pure (credential) storage example: https://www.graphengine.io/docs/manual/DemoApps/FriendsGraph.html
Pure agent, agent service endpoint, protocol, message example: https://www.graphengine.io/docs/manual/DemoApps/Ping.html
Far Left Self-Sovereignist
Self-Sovereign Blockchain Architect
Trusted Digital Web
Hyperonomy Digital Identity Lab
From: sds-wg@... <sds-wg@...>
On Behalf Of Adrian Gropper
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 https://github.com/w3c/did-core/issues/382 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 https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/ that makes no assumptions about the domain or functionality of my app https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/
IH3 - In the general case, the next step would be some kind of discovery. The request object should have
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.