Difference between revisions of "Trusted First Party"
From MgmtWiki
(→Problems) |
(→Problems) |
||
| Line 10: | Line 10: | ||
* Any party that holds [[User Information]] has the possibility of breach of trust that the information will not be released. | * Any party that holds [[User Information]] has the possibility of breach of trust that the information will not be released. | ||
* The user will have gone to some web site, then the user gets a request for authentication information for a sign-on process. | * The user will have gone to some web site, then the user gets a request for authentication information for a sign-on process. | ||
| − | ** The user is given a list of the claims that the RP needs to complete a sign-on process, but also needs to know | + | ** The user is given a list of the claims that the RP needs to complete a sign-on process, but also needs to know the ID of the responsible PII controller. |
** The attacker that wants to capture user credentials or just a hijack a user sign on session can provide the user with some official looking logos. | ** The attacker that wants to capture user credentials or just a hijack a user sign on session can provide the user with some official looking logos. | ||
** How is the user to know if they should continue with the sign on session? | ** How is the user to know if they should continue with the sign on session? | ||
Revision as of 21:04, 13 April 2021
Full Title or Meme
Any Web Site that the user trusts.
Context
- Identifying a Trusted First Party has traditionally been handled by the User Agent or browsers. in 2020 nearly all browsers insist that web sites have X509 SSL certificates unless the user decides to ignore the warnings that block easy access to the site.
- Single Sign-On providers have typically used commercial means to establish trust with users.
- With the arrival of Self-Issued IDs it is time to determine what measures need to be taken to assure the user of the identity of web sites that are requesting sign on information from the Identity Wallet on the user's device that provides the information on assurance of that user's Identifier to the Relying Party.
Problems
- Any party that holds User Information has the possibility of breach of trust that the information will not be released.
- The user will have gone to some web site, then the user gets a request for authentication information for a sign-on process.
- The user is given a list of the claims that the RP needs to complete a sign-on process, but also needs to know the ID of the responsible PII controller.
- The attacker that wants to capture user credentials or just a hijack a user sign on session can provide the user with some official looking logos.
- How is the user to know if they should continue with the sign on session?
Solutions
Some types of Trusted Third Party include:
- Privacy Enhancing Technology Providers (PETP) can protect user's privacy by anonymizing the User's Identifier. See Microsoft UProve.[1] or IBM Identity Mixer.[2]
- Governmental agencies that hold data for legitimate purposes will typically have a legal mandate to protect the data. Unfortunately they also have sovereign immunity should a breach be discovered.
References
Other Material
- A Trusted Third Party may be valuable in any use case where the user wants to be have some Assurance about privacy of data that does need to be shared in very limited circumstances.
