Difference between revisions of "Self-issued Trust"
From MgmtWiki
(→Problem) |
(→Solutions) |
||
| Line 18: | Line 18: | ||
* 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. | * 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. | ||
* There are two parts of the trust decision that can be standardized: | * There are two parts of the trust decision 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 data provided to the user and to the RP to enable a trust decision. For example: |
| + | ## a privacy policy or list of claims (attributes) required by an RP, hopefully accompanied with a clear statement of the use of those attributes. | ||
| + | ## a consent statement by a user. | ||
# The recording of the acceptance of the data and the user that is made of it. For example consent receipt from an RP based on that statement. | # The recording of the acceptance of the data and the user that is made of it. For example consent receipt from an RP based on that statement. | ||
Revision as of 07:03, 1 July 2021
Contents
Full Title or Meme
The core concept of Self-issued Identifiers is that the user can establish a trust relationship with a Relying Party (PR) that does not permit sharing of any part of that relationship with a Trusted Third Party.
Context
Trust as used here is a necessary condition for a party to undertake (or continue) an action.
Participants
- User
- Relying Party
- Trusted Third Party (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)
Problem
This entire concept is technically difficult (if not impossible) to pull off. None-the-less, trust decision are made continuously in any identifier-medicated transaction.
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.
- There are two parts of the trust decision that can be standardized:
- The data provided to the user and to the RP to enable a trust decision. For example:
- a privacy policy or list of claims (attributes) required by an RP, hopefully accompanied with a clear statement of the use of those attributes.
- a consent statement by a user.
- The recording of the acceptance of the data and the user that is made of it. For example consent receipt from an RP based on that statement.
Trust Relationshipts
- 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.
