Identity Hub Concept


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 
  • 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



Michael Herman (Trusted Digital Web)
 

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

 

Have fun,

Michael

 

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
To: sds-wg@dif.groups.io
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 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 

  • 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

 

 


Michael Herman (Trusted Digital Web)
 

…plus full support for Language Integrated Query (LINQ): https://www.graphengine.io/docs/manual/DataAccess/LINQ.html#language-integrated-query-linq

 

For example,

 

var positive_feedbacks = from user in Global.LocalStorage.User_Accessor_Selector()

                          from comment in user.comments

                          where comment.rating == Rating.Excellent

                          select new

                          {

                            uid = user.CellID,

                            pid = comment.ProductID

                          };

 

From: sds-wg@... <sds-wg@...> On Behalf Of Michael Herman (Trusted Digital Web)
Sent: July 21, 2021 9:07 PM
To: sds-wg@...; sds-wg@dif.groups.io
Subject: Re: [sds-wg] Identity Hub Concept

 

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

 

Have fun,

Michael

 

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
To: sds-wg@dif.groups.io
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 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 

  • 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

 

 


Michael Herman (Trusted Digital Web)
 

Adrian, here is a more tangible example of how I’m using Trinity to design, model, and implement what I call Structured Credentials.  I’d love your feedback.

 

You can design, implement, and test new functioning Structured Credential Agents in less than a day.

 

Structured Credentials for C# Developers: What is a Structured Credential?

https://www.youtube.com/watch?v=FFv4WZ0p3aY

 

 

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 Michael Herman (Trusted Digital Web)
Sent: July 21, 2021 9:07 PM
To: sds-wg@...; sds-wg@dif.groups.io
Subject: Re: [sds-wg] Identity Hub Concept

 

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

 

Have fun,

Michael

 

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
To: sds-wg@dif.groups.io
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 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 

  • 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