Web Platform Identifier
Revision as of 14:47, 30 April 2019 by Tom (talk | contribs) (Created page with "==Full Title or Meme== A Web Platform Identifier is a Trusted Identifier deployed by Entities that wish to project trust to [[User]s of the web either indiv...")
Full Title or Meme
A Web Platform Identifier is a Trusted Identifier deployed by Entities that wish to project trust to [[User]s of the web either individuals or enterprises.
- 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.
- 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.
- 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|
|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|
|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)|
It may be that some of these terms (like list of attributes) are better listed on the 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.
- 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.