|
|
| (7 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | [[Category:Articles that need updating]][[Category:Glossary]][[Category:Nodal Concepts]][[Category:Nodal Organisations]] | + | {{stub}} |
| − | <table class=document-code><tr><td>
| + | WebOfTrust introduce decentralized identifiers (DID) in their [https://github.com/WebOfTrustInfo/rwot7-toronto/blob/master/topics-and-advance-readings/did-primer.md DID primer] as follows. At a superficial level, a DID is simply a new type of globally unique identifier. But at a deeper level, DIDs are the core component of an entirely new layer of decentralised digital identity and public key infrastructure (PKI) for the Internet. This [https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/final-documents/dpki.pdf decentralised public key infrastructure] (DPKI) could have as much impact on global cybersecurity and cyberprivacy as the development of the [https://en.wikipedia.org/wiki/Transport_Layer_Security SSL/TLS protocol] for encrypted Web traffic (now the largest PKI in the world). |
| − | [[+Identity/Summary]]
| |
| − | </table>
| |
| | | | |
| − | =GUID creation=
| + | A DID is an address on the internet that someone called a subject (you, a company, a device) can "own" and control directly, like a username but randomly generated. It can be used to find a connected ''DID document'' which is like a business card, providing extra information for finding or contacting or checking the signatures of that subject; that subject can update or remove that ''listing'' over time, directly. |
| − | All GUID's no matter how they're made are all distinct binary sequences, the difference between GUID methodologies comes down to how a given node in the network gets issued with its unique bit sequence - ie how a given ''value'' gets its corresponding ''key''. Most P2P networks are built upon a ''[[w:DHT|distributed hash table]]'' where node identifiers are a hash of their content. This is an excellent solution for file-based networks because files are distinguished from each other by their content.
| |
| | | | |
| − | In object-oriented environments, identifers cannot be a function of content because an objects' reference should remain constant even though its state may be very dynamic. In this kind of environment, unique identifers are usually created from a combination of host information, local time and a random number (this could then be hashed so the identifers are of the same form as the content-hashes).
| + | Strictly speaking, a DID is a string that functions as an address. Sometimes people might use the term to refer ''both'' to the DID ''and'' the DID Document, When you use a ''DID Method'' to resolve the DID you get the associated DID Document. A DID without a DID Document is like a dead end! |
| | | | |
| − | =routing GUID queries= | + | == See also == |
| − | In a normal [[w:distributed hash table|distributed hash table]] the entire possible hash-space is given a geometry and then divided amongst the peers in a deterministic way (meaning they don't need to communicate with one another to be able to determine whether a hash-key is within their domain). The geometry allows shortest-path routes from one peer to another to be calculated.
| + | *[https://www.w3.org/2019/did-wg/ W3C DID Working Group] and [https://www.w3.org/TR/did-spec-registries/#did-methods DID methods] |
| − | | + | *[https://identity.foundation/faq/ Identity Foundation] |
| − | =The nodal GUID factory= | |
| − | The nodal model does '''not''' use ''hashes'', ''randomness'' or ''localtime'' as these are not based on fundamental principles and they do not scale perfectly, so they are not in accord with the foundation [[:Category:Philosophy|philosophies of the project]]. In an ''organised'' network, there is another solution to this unique-identifer problem. The problem was that nodes could not communicate together to reserve names in real-time due to node transiency and separation. But in an organised network, names can be treated like any other resource and be booked, reserved, merged and managed with the same processes that schedule and storage already use.
| |
| − | | |
| − | Identifiers are all binary sequences, they are created in response to demand as local ''id-stock'' falls too low. Ranges of unused id's are passed down the ''physical axis'' (explained below) on request because they are a network resource. The size of a requested id-range is based on the expected demand between the time of request and the next ''id meeting''. The size of id-ranges is always a power of two such that all id's in the range differ only in the least-significant-bits.
| |
| − | *A node does not need an identifier until it forms a relationship with a node outside the local peer-node. At runtime, direct memory references are used, universal identifiers are only needed for inter-peer communications. Later id-expiry and re-use will be implemented to reduce the growth rate of id-size. | |
| − | *The distributed application handling the GUID's (global unique identifers) does not need to be very dynamic since the size of the ranges being booked can increase to account for the period involved. Since dynamic bandwidth is more expensive in terms of energy, a slower cycle is perferred so it is set to 24 hourly.
| |
| − | | |
| − | =Methods=
| |
| − | The Identity organisation is the most commonly used organisation of all. It performs the following functions which are specific instances of the functions defined by [[resource]]. See [[generic organisation]] for more details.
| |
| − | *Range booking requests
| |
| − | *Statistics and information maintenance and requests
| |
| − | *Booking process
| |
| − | *Stock and budgetting
| |
| − | *Storage and distribution of information and GUID stock
| |
| − | | |
| − | =See also=
| |
| − | *[[Generic organisation]]
| |
| − | *[[Resource]]
| |
| − | *[[Storage and Distribution]]
| |
| − | *[[Nodal Reduction]]
| |
|
This article or section is a stub. Stubs are articles that have not yet received substantial attention from the authors. They are short or insufficient pieces of information and require additions to further increase the article's usefulness. The project values stubs as useful first steps toward complete articles.
|
|
WebOfTrust introduce decentralized identifiers (DID) in their DID primer as follows. At a superficial level, a DID is simply a new type of globally unique identifier. But at a deeper level, DIDs are the core component of an entirely new layer of decentralised digital identity and public key infrastructure (PKI) for the Internet. This decentralised public key infrastructure (DPKI) could have as much impact on global cybersecurity and cyberprivacy as the development of the SSL/TLS protocol for encrypted Web traffic (now the largest PKI in the world).
A DID is an address on the internet that someone called a subject (you, a company, a device) can "own" and control directly, like a username but randomly generated. It can be used to find a connected DID document which is like a business card, providing extra information for finding or contacting or checking the signatures of that subject; that subject can update or remove that listing over time, directly.
Strictly speaking, a DID is a string that functions as an address. Sometimes people might use the term to refer both to the DID and the DID Document, When you use a DID Method to resolve the DID you get the associated DID Document. A DID without a DID Document is like a dead end!
See also
