Trust in Self-Issued Identifiers

[Tom Jones]

The discussion about federation evolved into a discussion about trust. Here are the trust vectors i have so far discovered.

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.

i have more thought and will be tracking on this post https://tcwiki.azurewebsites.net/index.php?title=Self-issued_Trust

[Nat Sakimura]

June 30 call discussed whether we should have a normative text about it in SIOP v.2 etc.

• how user trusts
• what receipts the user gets

Refer to June 30 notes for more info.

[Tom Jones]

based on a suggestion by Nat here are some:

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

‌

[Jeremie Miller]

There’s a very big challenge hidden/implicit in 1.1 about what the RP states in order of the user to make a trust evaluation.

How do you know who the RP actually is?

Browsers have a UX lock icon and expect users to trust the domain name displayed.

App stores validate the developer name and display it when you choose to install.

Social media sites do their own validation and iconography.

What do we expect wallets to do to prevent fishing?

This is something that is an explicit function of a trust framework (like the AAMVA’s mDL Digital Trust Service), but is there any general solutions outside of vertical specific governance?

[Former user]

The problem statement as defined by Jeremie is actually the one I raised in the discussion about federations spec.

And I think it’s not only applicable to self-issued identities, but same way applicable to cloud-based OPs or Claim Providers (a.k.a. Issuers). Each party in the process shall be able to receive additional information about the other party supporting end-users and its own trust decisions.

Trust framework and governance is one of the main functions of a federation. The current specification only specifies how to express a binary releation: is a member of a federation or not, but not necessarily any qualitative information about the relation (like LoI) which could be digitally verified by the other parties.

[Mark Haine]

Migrated to GitHub

https://github.com/openid/SIOPv2