IOTA tutorial 22: Masked Authenticated Messaging Demo Verifiable Claims

If you like this video and want to support me, go this page for my donation crypto addresses:
https://www.youtube.com/c/mobilefish/about

This is part 22 of the IOTA tutorial.

In this video series different topics will be explained which will help you to understand IOTA.
It is recommended to watch each video sequentially as I may refer to certain IOTA topics explained earlier.

The main objective of this video is to demonstrate a Masked Authenticated Messaging use case.

MUNICIPALITY OF HAARLEM IOTA POC
In 2017, Xurux Solutions in collaboration with ICTU, were commissioned by the municipality of Haarlem (the Netherlands) to create a Proof-of-Concept in which the citizens of Haarlem logs into a website using an existing Identity Management System (called DigID) to retrieve a publicly verifiable claim.
This verifiable claim is in fact a QR code.
The QR code contains information such as the hash value of the citizens personal data, root and other relevant data.
This hash value, called the attest hash, is stored on the IOTA Tangle (MAM) using the previous mentioned root.
Third parties, like housing corporations, can easily prove these verifiable claims.
The QR code is scanned, to get the root and hash value.
The attest hash value can now be retrieved from the Tangle and compared with the one stored in the QR code.
See: https://github.com/Haarlem/digitale-waardepapieren

VERIFIABLE CLAIMS DEMO
Based on the municipality of Haarlem IOTA Proof-of-Concept I have created the “IOTA MAM Demo: Verifiable Claims”:
https://www.mobilefish.com/services/cryptocurrency/mam_verifiable_claims.html
This demonstration is created for educational purpose and is NOT the same as the Haarlem’s PoC.

VERIFIABLE CLAIMS DEMO EXPLAINED
Bruce requires an attestation from Gotham City stating that he is a resident of this city and he is eligible for social housing.
Gotham City issues a verifiable claim to Bruce, attesting that he is a resident of Gotham City and he meets all the conditions for social housing.
The claim is hashed (also known as attesthash) and stored on the Tangle using the Masked Authenticated Messaging in restricted mode.
Bruce shares this claim with the social housing cooperative because he wants to be eligible for a social rental home.

The social housing cooperative needs to verify that Bruce’s claim is signed by Gotham City.
The social housing cooperative does this by first hashing Bruce’s claim.
Let call this the “calculated attesthash”.
Next the social housing cooperative extracts the “stored attesthash” from the Tangle.
All relevant information, such as root and uuid are stored in Bruce’s claim.
If the “calculated attesthash” is the same as the “stored attesthash” than this is the proof that Gotham City has signed Bruce’s claim.

To make this all work Gotham City must provide the social housing cooperative with the side key because of the use of the Masked Authenticated Messaging restricted mode.
The social housing cooperative does not need to have any connection to or interaction with Gotham City.
Each time Bruce requests for a verifiable claim an Universally Unique IDentifier (UUID) is generated compliant with RFC-4122 Version 4.
One of the main reasons for using UUIDs is that no centralised authority is required to administer them.

The chance of generating the same UUID is quite small especially if the UUIDs are generated using sufficient entropy.
More information see:
https://en.wikipedia.org/wiki/Universally_unique_identifier

WHAT IS HMACSHA384
HMACSHA384 is a type of keyed hash algorithm that is constructed from the SHA-384 hash function and used as a Hash-based Message Authentication Code (HMAC).
The output hash is 384 bits in length.
An HMAC can be used to determine whether a message sent over an insecure channel has been tampered with, provided that the sender and receiver share a secret key.
The sender computes the hash value for the original data and sends both the original data and hash value as a single message.
The receiver recalculates the hash value on the received message and checks that the computed HMAC matches the transmitted HMAC.

Any change to the data or the hash value will result in a mismatch, because knowledge of the secret key is required to change the message and reproduce the correct hash value.
Therefore, if the original and computed hash values match, the message is authenticated.
Please note: In our demo the key for the HMACSHA384, which is the uuid, is not secret because MAM restricted mode is being used.

Check out all my other IOTA tutorial videos:
https://www.youtube.com/playlist?list=PLmL13yqb6OxdIf6CQMHf7hUcDZBbxHyza

Subscribe to my YouTube channel:
https://www.youtube.com/channel/UCG5_CT_KjexxjbgNE4lVGkg?sub_confirmation=1

The presentation used in this video tutorial can be found at:
https://www.mobilefish.com/developer/iota/iota_quickguide_tutorial.html

#mobilefish #howto #iota

IOTA tutorial 22: Masked Authenticated Messaging Demo Verifiable Claims

Related Post:

About The Author

Kane Dane