Difference between revisions of "Trusted Identifier"
From MgmtWiki
m (→References) |
(→Context) |
||
(26 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== | ||
+ | * 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 Cert]]s 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== | ==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. | ||
+ | {|border="1" padding="2" width="799px" | ||
+ | | 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|| bgcolor="SkyBlue"|RSA2048 (for example) | ||
+ | |- | ||
+ | | 10 ||Signature ||hex value|| bgcolor="SkyBlue"|134bbead23d908e0a3221bc | ||
+ | |} | ||
+ | It may be that some of these terms (like list of attributes) are better listed on the [[Trusted Location]]. | ||
==References== | ==References== | ||
− | *[[Trusted Location]] | + | * 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 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.