Difference between revisions of "Trusted First Party"
From MgmtWiki
(→Problems) |
(→Solutions) |
||
| (10 intermediate revisions by the same user not shown) | |||
| 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== | ||
| − | * In an era where new technologies have | + | * In an era where new technologies have demonstrably adversely impacted 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. | * 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. | ||
| Line 16: | Line 16: | ||
==Solutions== | ==Solutions== | ||
| − | Some types of [[Trusted | + | Some types of [[Trusted First 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. | * 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. | + | * Communities like finance or health care can create trust registries that test both web sites and wallets are used for high assurance access and make those available to users. |
| + | * Web browsers and the security services are informed what to expected of a well-bahavied site so that badly behaved sites can easily be identified and marked as suspicious. | ||
| + | * 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. There is already evidence that sovereign governments, like the State of Texas collects driver's license information and sells it to commercial enterprises on the promise that they will be well behaved. Therefore some trust registry needs to step up to evaluate the trustworthiness of sovereign entities. | ||
| + | |||
| + | For more details on creating a [[Trusted Identifier]] click on that name to go to the wiki page. | ||
==References== | ==References== | ||
| Line 25: | Line 29: | ||
* 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. | * 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. | ||
| − | |||
[[Category:Glossary]] | [[Category:Glossary]] | ||
[[Category:Authentication]] | [[Category:Authentication]] | ||
| + | [[Category:Identifier]] | ||
| + | [[Category:Privacy]] | ||
Latest revision as of 16:04, 8 July 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 demonstrably adversely impacted 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 First 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.
- Communities like finance or health care can create trust registries that test both web sites and wallets are used for high assurance access and make those available to users.
- Web browsers and the security services are informed what to expected of a well-bahavied site so that badly behaved sites can easily be identified and marked as suspicious.
- 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. There is already evidence that sovereign governments, like the State of Texas collects driver's license information and sells it to commercial enterprises on the promise that they will be well behaved. Therefore some trust registry needs to step up to evaluate the trustworthiness of sovereign entities.
For more details on creating a Trusted Identifier click on that name to go to the wiki page.
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.
