Difference between revisions of "Self-issued Trust"

Revision as of 16:01, 3 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.

To paraphrase Laotse, you cannot create trust with cryptography, no matter how much cryptography you use. — Jon Callas.

Context

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:

1. local level, for example which politician do I vote for, or which application do I install on my computer.
2. 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.

Participants

1. User (Subject)
2. Relying Party (RP)
3. Trusted Third Party (TTP that is kept ignorant of any association between the user and the RP)
4. User Agent (aka SIOP wallet)
5. Vendor Relationship Manager (aka Self-issued OpenID Picker, only needed if the user has more than one wallet)

Problems

• This entire concept is technically difficult (if not impossible) to pull off.
• See the Kantara Wiki Page on Patient Choice for details on existing smartphone app security.
• None-the-less, trust decision are made continuously in any identifier-mediated transaction.
• Thus trust decision are made with incomplete data.
• Even with good data users 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.
• Mobile Driver's Licenses (mDL) are currently issued by states, many of which have poor records at protecting user data on their computers. Texas continues to sell data from their Driver's License data base. Many states look to the DMV as s source of revenue rather than a delivery of user services.
• Given these failings, it is unlikely that user privacy will be well served by wallets that are not certified as protecting user secrets. That just is not the history of smart phone apps today.
• The release of large numbers of user digital wallets that are not certified is certain to destroy user trust in the whole concept of storing secrets on smart phone, which will poison the well for years to come.

Solutions

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

1. The data provided to the user and to the RP to enable a trust decision. For example:
   1. a privacy policy or list of claims (attributes) required by an RP, hopefully accompanied with a clear statement of the use of those attributes.
   2. a consent statement by a user.
2. 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.

• Kantara currently provides a certification program for user authentication at high levels of security. Such a service could be created for digital wallet certifications.
• See the Kantara Wiki Page on User Engagement for some ideas on creating a good ecosystem for good user choices.

Trust Relationshipts

1. The user trusts the RP to be telling the truth about its intent to honor the user's intentions wrt the user's data.
2. The user trusts the SIOP to be fairly representing the RP.
3. The user trusts the SIOP to protect the user's secrets (private keys and other credentials.)
4. The user trusts the SIOP to faithfully present user intent to the RP.
5. The RP trusts the SIOP to assist in the user authentication process (including user secrets and possibly user liveness.)
6. The users trusts the TTP (aka claims provider) to avoid releasing any information about them.
7. 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.)
8. Once a relationship is established the user trusts the VRM (chooser) to provide "refresh tokens" to quickly re-establish trust.

References