RE: [sds-wg] Identity Hub Concept

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

[cid:image003.jpg@01D7853D.95FE9DF0]



From: sds-wg@lists.identity.foundation <sds-wg@lists.identity.foundation> On Behalf Of Michael Herman (Trusted Digital Web)
Sent: July 21, 2021 9:07 PM
To: sds-wg@lists.identity.foundation; 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

[cid:image004.jpg@01D7853D.95FE9DF0]



From: sds-wg@lists.identity.foundation<mailto:sds-wg@lists.identity.foundation> <sds-wg@lists.identity.foundation<mailto:sds-wg@lists.identity.foundation>> On Behalf Of Adrian Gropper
Sent: July 21, 2021 8:30 PM
To: sds-wg@dif.groups.io<mailto: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


_._,_._,_
________________________________
Links:

You receive all messages sent to this group.

View/Reply Online (#156)<https://lists.identity.foundation/g/sds-wg/message/156> | Reply To Group<mailto:sds-wg@lists.identity.foundation?subject=Re:%20Re%3A%20%5Bsds-wg%5D%20Identity%20Hub%20Concept> | Reply To Sender<mailto:mwherman@parallelspace.net?subject=Private:%20Re:%20Re%3A%20%5Bsds-wg%5D%20Identity%20Hub%20Concept> | Mute This Topic<https://lists.identity.foundation/mt/84371777/1997675> | New Topic<https://lists.identity.foundation/g/sds-wg/post>
Your Subscription<https://lists.identity.foundation/g/sds-wg/editsub/1997675> | Contact Group Owner<mailto:sds-wg+owner@lists.identity.foundation> | Unsubscribe<https://lists.identity.foundation/g/sds-wg/leave/9912086/1997675/2030013897/xyzzy> [mwherman@parallelspace.net]
_._,_._,_