•••

•

••

••

•

•

•

•

•

A detailed technical discussion about the security algorithms and mechanism can be found in the Guideline for Using Cryptographic Standards in the Federal Government. [26]

(Alice, Bob, Charlie and Dave)

(Alice-Bob, Alice-Charlie, Alice-Dave, Bob-Charlie, Bob-Dave and Charlie-Dave)

•

•

•

•

••

•

•

•

•

•

•

••••

The corresponding Mist addressing syntax differs to some extent from the traditional URI syntax. The differences are required for wrapping any interesting communication protocol into the trust-based network communication, which already defines the scheme for the traditional URI. The Mist URI introduces new elements such as luid (local user identity), ruid (remote user identity), rsid (remote service identity) and rhid (remote host identity) as reveals. These are all 32 byte identifiers each (and each id can thereby be represented by 64 hexadecimal characters, which would make the address difficult to read).

The URI scheme field is defined by the static string “wish” as shown in , which refers to the encrypted trust based peer-to-peer communication within Mist. The purpose of this part is to allow the operating system to map to appropriate application which need to be launched to handle the address. The address also needs to define which trust-based relation shall be used for communication, therefore a tuple of local user id and remote user id is required, where the local user id is optional. The local user id can be used for defining which local identity shall be used, but in case the address is sent as a hyperlink to someone else, the local user id shall be excluded and the recipient need to use his own identity (in case he has several, then he need to point out which of them). Next to the relation comes the authority part, which is defined by a tuple of remote host id and the remote service id. Both of them are hex formatted strings with 64 characters each. Notice that no IP address or host address is defined in the authority. Instead, the remote user id is used to automatically resolve the network addresses. This is a very important aspect, which brings several very significant advantages: 1) the trust-based network can span over several underlying protocols and technologies (IPv4, IPv6, or almost any addressable network protocol), and 2) the trust-based network addressing provides roaming features, where any part can change their network address (IP address) at any time, and the new network address can automatically be resolved and the communication continues as before. After the authority part comes the scheme definition, which corresponds to the scheme defined in the traditional URI. The scheme defines which application protocol shall be communicated over the trust-based network (with the previously defined remote service). The rest of the addressing is not always applicable or used. Depending on the type of service, the hierarchical part, query part and fragments may or may not be applicable and available. For instance, the Mist IoT service, which is defined by the “mist” scheme, provides a hierarchical part for accessing the resources within the

http://www.ietf.org/rfc/rfc2396.txt ldap://[2001:db8::7]/c=GB?objectClass?one news:comp.infosystems.www.servers.unix tel:+1-816-555-1212 telnet://192.0.2.16:80/

URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty

"wish"://[luid>]ruid@rhid/rsid?scheme[hier-part["?" query]["#" fragment]]

service (endpoints of the system model), but does not support queries or fragments. This proposed URI like representation of the addressing in Mist is primarily described in order to relate to the traditional URI syntax, and is not (at least yet) implemented. The proposed syntax is justified, but the readability has suffered a lot, and therefore it’s very inconvenient to type manually, unless special tools are

developed for the purpose. The main reason for the poor readability is the four 64 characters long hexadecimal strings, which represents the ids. Of course, all of these id strings have their human readable alias, which could be used in the address, but the previously mentioned tool would need to translate these strings to the globally unique ids before any kind of communication or serialization for export. The syntax could possibly be useful for hyperlinks, for instance to be stored in NFC tags, and could probably benefit of URI support in legacy systems.

wish://[luid>]ruid@rhid/rsid?foo/over/there?name=ferret#nose \_/ \__/ \__/ \__/ \__/ \__/\________/ \_________/ \__/ | | | \ \ \__ \ | | static local remote remote remote scheme path query fragment user user host service \________/ \____________/ | | relation authority

wish://alice>bob@phone/messenger?chat wish://alice>bob@server/BobsWebsite?HTTP wish://alice>bob@zigbeeGateway?mist/LivingRoomWallLamp

•

•

•

•

••

•

•

•

•

A.J. Han Vinck, University of Duisburg-Essen SVG version: Flugaal - A.J. Han Vinck, Introduction to public key cryptography, p. 16

Elaine Barker, William C. Barker “Guideline for Using Cryptographic Standards in the Federal Government: Directives, Mandates and Policies” Draft NIST Special Publication 800-175A (2016)

Daniel J. Greenwood, ‘Risk and Trust Management Techniques for an “Open But Bounded” Public Key Infrastructure’, 38 Jurimetrics J. 277-294 (1998)

{"typ":"JWT", "alg":"HS256"}

eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9

{ "sub": "1234567890", "name": "John Doe", "admin": true }

eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9

.

eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt

cGxlLmNvbS9pc19yb290Ijp0cnVlfQ

.

dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

Authorization: Bearer <token>