Awesome-Mirrors/decentralized-id.github.io
1
0
Fork 0
mirror of https://github.com/Decentralized-ID/decentralized-id.github.io.git synced 2024-09-06 09:04:36 +00:00
Code Issues Packages Projects Releases Wiki Activity
2395f6d86f
decentralized-id.github.io/unsorted/guardianship.md
⧉ infominer 30830c6da4 new posts \ sort
2023-06-18 05:09:46 +05:30

13 KiB
Raw Blame History

published
false

Guardianship

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

  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.

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

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

  • [...]

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

A password manager that puts the user in full control.  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.

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

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/

  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

  33. https://www.researchgate.net/publication/348325716_Decentralized_SSI_Governance_the_missing_link_in_automating_business_decisions

Quick intro outline: 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.

  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:

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.

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