Difference between revisions of "Trusted Identifier"
From MgmtWiki
(→Context) |
(→Context) |
||
Line 6: | Line 6: | ||
*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]]. | *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. | *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. | + | *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.] |
==Problems== | ==Problems== |
Revision as of 13:41, 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.
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.