Difference between revisions of "Trusted First Party"
From MgmtWiki
(→Context) |
(→Context) |
||
| Line 5: | Line 5: | ||
* 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. | * 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. | * [[Single Sign-On]] providers have typically used commercial means to establish trust with users. | ||
| − | * With the arrival of [[Self- | + | * With the arrival of [[Self-issued Identifier]]s 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== | ==Problems== | ||
Revision as of 21:19, 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 Identifiers 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
- In an era where new technologies have been shown to adversely impact user privacy, any new technology will receive increased scrutiny.
- 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:
- A privacy responsible web site acquires a credential that can generate a presentment (or even a X.509 certificate) that the user can trust.
- 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.
