decentralized-id.github.io/identosphere-dump/user-experience/guardianship.md

---
published: false
---

# Guardianship
* [Guardianship In Self-Sovereign Identity](http://thedinglegroup.com/blog/2020/11/30/guardianship-in-self-sovereign-identity)

* [Video] [Vienna Digital Identity Meetup #17](https://vimeo.com/482803989)
  > Guardianship is a complex topic, with many subtleties and layers [...]  In this first event on this topic, Philippe has provided an overview of how SSI and Guardianship fit together and how SSI meets the lifecycle stages (Inception, Creation, Usage and Termination) of guardianship.
* [The Sovrin Working Group Tech Requirements and Implementation Guidelines](https://docs.google.com/presentation/d/1aGTPmlno3WScpSYMs1HLhWsrVRx9B-I0yhOQsRgmqRw/edit?usp%3Dsharing) John Phillips, Jo Spenser
  > Sovrin is looking to promote the governance process and where guardianship fits in.  The IdRamp wallet is an example of how the wallet could provide helpful features.
* [A Deeper Understanding of Implementing Guardianship](https://sovrinid.medium.com/a-deeper-understanding-of-implementing-guardianship-9a8ab749db90)

* [A Deeper Understanding of Implementing Guardianship](https://sovrinid.medium.com/a-deeper-understanding-of-implementing-guardianship-9a8ab749db90): Two new Guardianship papers from Sovrin at IIW #32
  > The first paper is called the [Guardianship Credentials Implementation Guidelines](https://drive.google.com/file/d/1vBePVx8n3MRDWcePkwVDya9ab4BHEyU_/view?usp%3Dsharing) and its purpose is to provide readers with the background they need to implement IT systems that support various kinds of guardianship. The second paper is called [Guardianship Credentials Technical Requirements](https://drive.google.com/file/d/1M21PznPAd0H6z1t4ODl-jiEoXZjEhwcb/view?usp%3Dsharing) which was developed by the technical requirements working group within the SGWG. The purpose of this document is twofold: i) provide principles under which guardianship scenario designs and requirements are considered and defined; and ii) provide technical requirements for SSI solutions that offer the capability of guardianship.

* [Internet Governance - UDDI - Universal Declaration of Digital Identity](https://iiw.idcommons.net/10I/_Internet_Governance_-_UDDI_-_Universal_Declaration_of_Digital_Identity) by Jeff Aresty, Kristina Yasuda

Internet governance, human rights, digital identity, Identity for All, Guardianship

* [Guardianship Showcase - The Sovrin Working Group Tech Requirements and Implementation Guidelines](https://iiw.idcommons.net/4G/_Guardianship_Showcase_-_The_Sovrin_Working_Group_Tech_Requirements_and_Implementation_Guidelines) by John Phillips, Jo Spenser

* [Guardianship, SSI, and the Sovrin Guardianship WG - Update for IIW #32](https://docs.google.com/presentation/d/1aGTPmlno3WScpSYMs1HLhWsrVRx9B-I0yhOQsRgmqRw/edit?usp%3Dsharing)

1. Jurisdictions are essential [to Guardianship]
2. Work with existing laws
3. Build Guardianship on Verifiable Credentials
4. Build a mental model
5. Don’t build Guardianship [solely] on wallets

Sovrin is looking to promote the governance process and where guardianship fits in.  The IdRamp wallet is an example of how the wallet could provide helpful features.

- Universal Wallet: [https://w3c-ccg.github.io/universal-wallet-interop-spec/](https://w3c-ccg.github.io/universal-wallet-interop-spec/)
- Review/contribute to the draft spec (or portions you’re interested in): [https://docs.google.com/document/d/1vPqb4bJ6pfuAPYF_fMW_Lb-7GZugasWKfrSCotpuv6o/edit#](https://docs.google.com/document/d/1vPqb4bJ6pfuAPYF_fMW_Lb-7GZugasWKfrSCotpuv6o/edit%23)
- Verifiable Credentials for Education Task Force: [https://w3c-ccg.github.io/vc-ed/](https://w3c-ccg.github.io/vc-ed/)

* [Agency By Design (Privacy is not Enough)](https://iiw.idcommons.net/20B/_Agency_By_Design_(Privacy_is_not_Enough)) by Adrian Gropper

Agency vs. Delegation

Learning Stack:

- Me
- My Agent / Fiduciary / semi-autonomous
- Community
- Vendors and Institutions

Relationship with companies

- Dashboard for our lives
- Portable shopping cart

CAPCHAS

- Browser is not enough
- Force APIs
- GNAP
- API in healthcare

How would an API World function

- Intelligence
- Choice

The GNAP at  the IETF: [https://tools.ietf.org/html/draft-ietf-gnap-core-protocol-04](https://tools.ietf.org/html/draft-ietf-gnap-core-protocol-04)

Is server a bad concept

- Ethereum as the ultimate server

Clear application? Needed a model how a real human uses / not the tech / highly motivated

Social Context is important to the average user

The back end is most important

Real estate “agents” vs. DSIY - Zillow - the GNAP RFC at the IETF: [https://tools.ietf.org/html/draft-ietf-gnap-core-protocol-04](https://tools.ietf.org/html/draft-ietf-gnap-core-protocol-04)

* [...]

HTML and JSON / OAuth 2.0 Token Exchange - support for delegation semantics ( [https://tools.ietf.org/html/rfc8693](https://tools.ietf.org/html/rfc8693)  )

A password manager that puts the user in full control.  [https://sitepassword.alanhkarp.com/](https://sitepassword.alanhkarp.com/)

* [...]

Agency by Design (Privacy is not Enough)

Adrian Gropper:

I’m not a fan of Privacy by Design.

In the industry are only concerned about compliance, very rarely talk about Human Agency

Privacy by Default is the opposite in some sense to privacy by design

The problem is that It conflict with community in many cases. (e.g. social credit score)

Cultural differences (EU accepts better centralization than US)

Delegation and agency are one the same thing

Agency is a much bigger thing and delegation is a mechanism that supports it

I want my fiduciaries to know as much as possible of me (e.g. my doctor, my lawyer)

Model Agency as hierarchy and delegation is the mean to have it.

* [...]

* [Why you know less about Guardianship than you think (because we ALL know less about Guardianship than we think)](https://iiw.idcommons.net/20L/_Why_you_know_less_about_Guardianship_than_you_think_(because_we_ALL_know_less_about_Guardianship_than_we_think)) by Jo Spencer, John Phillips, Sterre den Breeijen

Link to the deck we’ll use to start the conversation: [https://docs.google.com/presentation/d/1aGTPmlno3WScpSYMs1HLhWsrVRx9B-I0yhOQsRgmqRw/edit?usp=sharing](https://docs.google.com/presentation/d/1aGTPmlno3WScpSYMs1HLhWsrVRx9B-I0yhOQsRgmqRw/edit?usp%3Dsharing)

Do we need to get more people interested in the “real life” application of

Four groups of people at IIW conferences?

- Technologists
- Idealists
- Pragmatists
- Entrepreneurs
1. In 2019 the Sovrin Foundation published a whitepaper on Guardianship; transitioned into the Working Group
2. APAC and NA/EMEA WG meetings
3. 2 key documents from the WG are going to be published by Sovrin Foundation - [https://sovrin.org/a-deeper-understanding-of-implementing-guardianship/](https://sovrin.org/a-deeper-understanding-of-implementing-guardianship/)
4. Implementation guidelines
5. Technical requirements
6. Why are we looking at Guardianship and SSI?
7. Guardianship is a part of life - we are rarely fully self-sovereign or independent
8. Guardianship is not a part of SSI at this moment - is a missing ingredient in our digital lives
9. The group thought guardianship was a simple concept
10. Small set of SSI building blocks …
11. Gap between use cases and requirements was too broad (see slides)
12. A mental model for guardianship was required (see IIW30 and IIW31 for further context)
13. ‘Squiggle’ - the journey
14. 5 things the team worked out
15. Jurisdictions are essential (gives meaning to the guardianship relation)
16. Should work with existing laws
17. Guardianship can be built on verifiable credentials
18. Build a mental model (and test it) - 15 functional requirements, 6 technical requirements, 3 validator requirements
19. Don’t build guardianship solely on wallets (mitigate the risk of wallet takeover and impersonation)
20. Transparent vs Opaque guardianship scenario
21. 5 things to consider
22. Should discovery be enabled
23. Ensuring appropriate representation
24. Receiving parties are key
25. Balancing agency, dignity and care
26. Transitions : recovery, expiry and ends
27. Alignment with SSI and ToIP
28. Guardianship creates a tension between independence and dependence
29. An obvious relationship with the ToIP (the ToIP model/diagram)
30. Mapping concepts of Guardianship with the Trust Triangle diagram
    
    ---
    
31. Parties, Actors and Action pattern
32. [https://essif-lab.pages.grnet.gr/framework/docs/notations-and-conventions](https://essif-lab.pages.grnet.gr/framework/docs/notations-and-conventions)
33. [https://www.researchgate.net/publication/348325716_Decentralized_SSI_Governance_the_missing_link_in_automating_business_decisions](https://www.researchgate.net/publication/348325716_Decentralized_SSI_Governance_the_missing_link_in_automating_business_decisions)

* [What if the Credential Subject cannot be the Holder?](https://iiw.idcommons.net/20H/_What_if_the_Credential_Subject_cannot_be_the_Holder%253F) by Sam Curren

Quick intro outline: [https://hackmd.io/HhLGtxBPSeGpxtp30S5tOg](https://hackmd.io/HhLGtxBPSeGpxtp30S5tOg)

Where is the line at the limits of what a holder can hold?

How is user consent managed?

What are the protocols like?

How does this tie into OAuth, GNAP, etc?

How does this relate to DIDComm Credential Exchange Protocols and Secure Data Stores?

It’s possible that the intent of the law is not being met, if a provider refuses to share data on behalf of a user.

OpenID has a function for distributed claims that provide a URI and an access token for retrieval.

JWTs have AZP - The authorized presenter of a credential. The issuer may be the authorized presenter.

If the issuer wants to use existing protocols, a credential can be issued which functions as a ‘shadow’ of the main credential. Presenting the shadow credential provides consent for the verifier to ask for a presentation of the main credential from the issuer.

* [Identity Escrow - Accountability AND Privacy](https://iiw.idcommons.net/11I/_Identity_Escrow_-_Accountability_AND_Privacy) by Sam Curren, Ken Ebert, Suresh Batchu, Kiran Addepalli

1. Can the escrow hold the "Proof of the information" as opposed to the information itself.
2. Mortgage Service - might seem to be an authorization to access the data directly or the issuer present directly.
3. What gets put into escrow is flexible.
4. Trigger event or a lockbox kind of capability. How is the claim released to relying parties? How does it eliminate mischief and false claims.
5. There needs to be some accountability on the service provider to claim false releases. Automation may not be able to completely eliminate false triggers, some level of human intervention for complex cases.
6. Contractual wrapper for
7. Technical and legal framework for accountability.
8. Don’t have data but key to unlock the escrow. So that no insider can unlock the data. Separating the data release from the encryption release would be better.
9. It is better to hold proof of data. Because of the risk and liability, it can create incentives to escrow providers.
10. We should chat about the CDDE (Community Distributed Data Escrow) that we have developed with UN, WEF, NYU Gov lab for data handling in disaster settings. Very related to this. Blind trust, etc. for self shielding.

* [...]

Links that came up during the call:

- [https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1430-9134.2001.00173.x](https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1430-9134.2001.00173.x)
- [https://dhh1128.github.io/zkpcreds/trust-paradox-rebuttal.html](https://dhh1128.github.io/zkpcreds/trust-paradox-rebuttal.html)
- Feedback loop into privacy law: [https://kantarainitiative.org/confluence/display/WA/Privacy+as+Expected%3A+UI+Signalling+a+Consent+Gateway+For+Human+Consent](https://kantarainitiative.org/confluence/display/WA/Privacy%2Bas%2BExpected%253A%2BUI%2BSignalling%2Ba%2BConsent%2BGateway%2BFor%2BHuman%2BConsent)

* [https://link.springer.com/chapter/10.1007/978-3-540-45146-4_8](https://link.springer.com/chapter/10.1007/978-3-540-45146-4_8)

* [Let’s Go - Together!: Does international travel only ever involve independent adults?](https://trustoverip.org/blog/2021/11/24/lets-go-together/) ToIP

Applying the developed models of guardianship, using the flexibility of Verifiable Credentials and the trusted mechanisms of sharing VCs, can provide the ability to add guardianship credentials into the travel process (or not) without breaking the existing approach and complicating the technical details defined in the Blueprint.

* [Delegatable Credentials Now Available](https://blog.dock.io/delegatable-credentials-now-available/)
  > An issuer may [grant delegation authority to another issuer](https://docknetwork.github.io/sdk/tutorials/concepts_private_delegation.html) simply by issuing them a vcdm credential. Let's say did:ex:a wants to grant delegation authority to did:ex:b. did:ex:a simply issues the credential saying that did:ex:b may make any claim.
* [Common Delegation Patterns in the Verifiable Credential Ecosystem](https://kyledenhartog.com/delegation-in-verifiable-credentials/) Kyle Den Hartog

did you know that there are three ways in which you can utilize VCs and DIDs to enable delegation [...] look to the [ZCAP-LD data model](https://w3c-ccg.github.io/zcap-ld/) which is designed especially for these concepts. And if you’re still confused and would like some help please reach out and I can see how I can help.