Difference between revisions of "Self-issued Trust"
(→Full Title or Meme)
|Line 1:||Line 1:|
==Full Title or Meme==
==Full Title or Meme==
The core concept of [[Self-issued Identifier]]s is that the user can establish a trust relationship with a [[Relying Party]] (
The core concept of [[Self-issued Identifier]]s is that the user can establish a trust relationship with a [[Relying Party]] () that does not permit sharing of any part of that relationship with a [[Trusted Third Party]].
Revision as of 17:12, 1 July 2021
Full Title or Meme
The core concept of Self-issued Identifiers is that the user can establish a trust relationship with a Relying Party (RP) that does not permit sharing of any part of that relationship with a Trusted Third Party.
Trust as used here is a necessary condition for a party to undertake (or continue) an action. There are many levels where trust decisions are needed, we will consider these two:
- local level, for example which politician do I vote for, or which application do I install on my computer.
- system level. When trust is gone, revolution might be required. Unfortunately revolutions seldom deliver the expected results. In other words, the cure can be worse than the disease.
- Relying Party (RP)
- Trusted Third Party (TTP that is kept ignorant of any association between the user and the RP)
- User Agent (aka SIOP wallet)
- Vendor Relationship Manager (aka Self-issued OpenID Picker, only needed if the user has more than one wallet)
- This entire concept is technically difficult (if not impossible) to pull off. None-the-less, trust decision are made continuously in any identifier-mediated transaction.
- Thus trust decision are main with incomplete data.
- User habitually make poor trust decisions online.
- Vendors continuously depend on bad user choice which results in loss of trust in the entire system.
- The W3C VC and DID core specs talk about trust of the wallet, but no where describe how that might be assured.
- It is definitely true, as the old adage states, that all authorization is local. What that means is that a local server will make a trust decision about what resources to provide. This is the essence of a Zero Trust Architecture.
- There are two parts of the trust decision process that can be standardized:
- The data provided to the user and to the RP to enable a trust decision. For example:
- a consent statement by a user.
- The recording of the acceptance of the data and the use that is to be made of it. For example, a consent receipt from an RP based on that statement.
- The user trusts the RP to be telling the truth about its intent to honor the user's intentions wrt the user's data.
- The user trusts the SIOP to be fairly representing the RP.
- The user trusts the SIOP to protect the user's secrets (private keys and other credentials.)
- The user trusts the SIOP to faithfully present user intent to the RP.
- The RP trusts the SIOP to assist in the user authentication process (including user secrets and possibly user liveness.)
- The users trusts the TTP (aka claims provider) to avoid releasing any information about them.
- The RP trusts the TTP to validate claims (offline proofs preferred over online verification of current state. Currently a huge debate within mDL/eID efforts.)
- Once a relationship is established the user trusts the VRM (chooser) to provide "refresh tokens" to quickly re-establish trust.