Difference between revisions of "Trusted Identifier"
From MgmtWiki
(→References) |
(→Context) |
||
| (13 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | A [[Trusted Identifier]] is deployed by [[Entity|Entities]] that wish to | + | A [[Trusted Identifier]] is deployed by [[Entity|Entities]] that wish to have [[Identifier]]s on the internet related to the real-world [[Identity]] that enable [[Recovery]] in the case of loss of access. |
==Context== | ==Context== | ||
*As a part of having a [[Trusted Identity in Cyberspace]] a series of [[Framework Profile]]s have been created to allow digital [[Entity|Entities]] to give users a statement about the policies that they support. | *As a part of having a [[Trusted Identity in Cyberspace]] a series of [[Framework Profile]]s have been created to allow digital [[Entity|Entities]] to give users a statement about the policies that they support. | ||
| + | *Individuals have [[Identifier]]s that must be associated with the real world person even if access to that [[Identifier]] is lost for any reason. Health care is one good requirement for a [[Trusted Identifier]]. | ||
| + | *Legal entities, like corporations, are not permitted to hide their real world [[Identity]] although many jump though many legal loopholes to try to distance themselves from discovery. | ||
| + | *A [https://tools.ietf.org/html/rfc7591#section-2.3 software statement] is a [https://tools.ietf.org/html/rfc7519 JSON Web Token (JWT)] that asserts metadata values about the client software as a bundle. It is also defined in the [https://openbanking.atlassian.net/wiki/spaces/DZ/pages/36667724/The+OpenBanking+OpenID+Dynamic+Client+Registration+Specification+-+v1.0.0-rc2#TheOpenBankingOpenIDDynamicClientRegistrationSpecification-v1.0.0-rc2-SoftwareStatementAssertion(SSA) UK Open banking standards.] Whatever it might have been designed to accomplish, it has been used to identifier the owner of a [[Web Site]] endpoint. It will typically include some sort of GUID for the specific instance, but that is often incidental to its real use as a [[Web Platform Identifier]]. | ||
==Problems== | ==Problems== | ||
| Line 14: | Line 17: | ||
#That [[Identity]] statement MAY be accessed at multiple locations that are locale specific for language or other purposes. | #That [[Identity]] statement MAY be accessed at multiple locations that are locale specific for language or other purposes. | ||
#That [[Entity]] will have a standard [[URN]] of the form TID:framework:LUID, where the framework will represent a set of rules that the [[Entity]] agrees to follow in all of its online transactions. | #That [[Entity]] will have a standard [[URN]] of the form TID:framework:LUID, where the framework will represent a set of rules that the [[Entity]] agrees to follow in all of its online transactions. | ||
| + | ##For example, in the US health care framework, TID:USHHS:CMS:3KW0-JW2-MY06 could represent an entity in the US under Medicare. | ||
Contents of site at the [[URL]] for the [[Trusted Identifier]] will be available in machine and human readable form. | Contents of site at the [[URL]] for the [[Trusted Identifier]] will be available in machine and human readable form. | ||
| Line 44: | Line 48: | ||
==References== | ==References== | ||
* The wiki page [[Trusted Location]] describes a solution to the problem on not knowing the trustworthiness or intent of a web page that is displayed on a user's browser window. | * The wiki page [[Trusted Location]] describes a solution to the problem on not knowing the trustworthiness or intent of a web page that is displayed on a user's browser window. | ||
| − | *[https://www.iana.org/assignments/well-known-uris/well-known-uris.xml Existing .well-known additions to URLs] can be seen for | + | *[https://www.iana.org/assignments/well-known-uris/well-known-uris.xml Existing .well-known additions to URLs] can be seen, for example, .well-known/tid could be a possible use for getting the [[Trusted Identifier]] statement as an HTTP URL. Normally it would use the TID:... as the URL. |
| + | *A [https://www.w3.org/TR/verifiable-claims-data-model/ Verified Claim] can carry some of the same information that might be found in an Identifier Statement. | ||
[[Category:Glossary]] | [[Category:Glossary]] | ||
| + | [[Category:Identifier]] | ||
| + | [[Category:Trust]] | ||
Revision as of 14:44, 30 April 2019
Full Title or Meme
A Trusted Identifier is deployed by Entities that wish to have Identifiers on the internet related to the real-world Identity that enable Recovery in the case of loss of access.
Context
- As a part of having a Trusted Identity in Cyberspace a series of Framework Profiles have been created to allow digital Entities to give users a statement about the policies that they support.
- Individuals have Identifiers that must be associated with the real world person even if access to that Identifier is lost for any reason. Health care is one good requirement for a Trusted Identifier.
- Legal entities, like corporations, are not permitted to hide their real world Identity although many jump though many legal loopholes to try to distance themselves from discovery.
- A software statement is a JSON Web Token (JWT) that asserts metadata values about the client software as a bundle. It is also defined in the UK Open banking standards. Whatever it might have been designed to accomplish, it has been used to identifier the owner of a Web Site endpoint. It will typically include some sort of GUID for the specific instance, but that is often incidental to its real use as a Web Platform Identifier.
Problems
- See the wiki page on Trusted Location for a list of the ways that a URL can be spoof to see why it is a bad idea to expect users to get a Trusted Identifier from a URL.
- EV Certs were introduced to give user's good knowledge of who was behind a web site. They didn't work out as planned as shown on the EV Cert wiki page.
Solutions
- Every real world Entity, be it a legal Entity or a legal name, like a Brand will have one place on the web for making an Identity statement.
- That Identity statement MUST be accessed by a URL at a well-known location in a relevant domain.
- That Identity statement MAY be accessed at multiple locations that are locale specific for language or other purposes.
- That Entity will have a standard URN of the form TID:framework:LUID, where the framework will represent a set of rules that the Entity agrees to follow in all of its online transactions.
- For example, in the US health care framework, TID:USHHS:CMS:3KW0-JW2-MY06 could represent an entity in the US under Medicare.
Contents of site at the URL for the Trusted Identifier will be available in machine and human readable form.
| N0, | Name | Typical use | User Experience |
| 1 | Identifier | URN | TID:framework:LUID |
| 2 | List of required user attributes | always needed | proof of presence (for example) |
| 3 | List of requested user attributes | above and beyond the above | passport, drivers license |
| 4 | Privacy policy | URL | DOI or URN |
| 5 | Terns of use | URL | DOI or URN |
| 6 | Legal Name | string(locale) | Company name registered with state |
| 7 | Legal Address | structure(locale) | street, city, country |
| 8 | Contact information | structure(locale) | mailto: phone fax, etc. |
| 9 | Signature Type | fixed list | RSA2048 (for example) |
| 10 | Signature | hex value | 134bbead23d908e0a3221bc |
It may be that some of these terms (like list of attributes) are better listed on the Trusted Location.
References
- The wiki page Trusted Location describes a solution to the problem on not knowing the trustworthiness or intent of a web page that is displayed on a user's browser window.
- Existing .well-known additions to URLs can be seen, for example, .well-known/tid could be a possible use for getting the Trusted Identifier statement as an HTTP URL. Normally it would use the TID:... as the URL.
- A Verified Claim can carry some of the same information that might be found in an Identifier Statement.
