<aside> <img src="/icons/info-alternate_gray.svg" alt="/icons/info-alternate_gray.svg" width="40px" /> tl;dr: the idOS requires signatures to work; transactions are optional, but awesome
The idOS is chain-agnostic, and the simplest idOS integration doesn’t involve the chain at all. However, access grants — which you and your users will want to use — require transactions on a blockchain.
Reading or writing data on idOS is done by making requests to idOS nodes. Many different types of requests are possible, such as reading the credential with ID 42, deleting the wallet with address 0x36e, or creating a twitter_handle attribute with value @idOS_network.
All requests must be signed (i.e. contain a signature). When an idOS node receives a signed request, it will authenticate and authorize its signer before complying with the request.
For the signer of a data request to authorize successfully, one of two things must be true: either they (your users) are the data owner, or they (you) got an access grant from the data owner.
These requests are very easy for dapps to make using the idOS SDK, because it abstracts a lot of this complexity away. If a dapp asks the SDK for user data, the SDK will pop the user’s wallet to ask them for a signature, use it to build the request, send it to a node and return the node’s response to the dapp.
idOS nodes always authenticate and authorize read and write requests based on a signature. For a data request to successfully pass authentication and authorization, this signature must be verifiable.
In theory, any ed25519 signing tool could be used to sign idOS requests. In practice, since key management is neither a common nor an expectable practice in userland, most users will rely on their crypto wallet for signatures.
This is why, aside from vanilla ed25519, idOS nodes also support two popular signer classes:
secp256k1 signatures (aka personal_sign)ed25519 signatures (aka signMessage)If your wallet supports any of these signature methods, it will work out of the box for you and your users. Otherwise, we need to talk: keep reading.
In most cases, reading and writing data from an idOS node is something that only your users, who are sovereign over their data, can do. While this is great, the full power of the idOS is unlocked with access grants.
Access grants allow idOS nodes to serve requests whose signer is not a data owner (e.g., it’s you, not your users). This is done with an extension to the authorization process, which looks on chain for access grants matching the requested data.
To use access grants, you must secure user consent. This consent must be recorded on chain such that it’s possible to demonstrate that it was indeed created by a data owner. An access grant simply needs to state that 0xAlice grants 0xBob access to record 123.
When requesting an access grant from a user, you may also request a timelock, which prevents this user from revoking the access grant or changing/deleting its underlying data until the timelock expires.