Features
DID with Ethereum address
This feature enables the creation of Ethereum-controlled identities. Ethereum accounts are used here to authenticate, prove statements and control identity.
The representation of the DID for this case follows the same canonical form, where the identifier 2qCU58EJgrELSJT6EzT27Rw9DhvwamAdbMLpePztYq actually originates from the Ethereum address:
did:polygonid:polygon:amoy:2qCU58EJgrELSJT6EzT27Rw9DhvwamAdbMLpePztYq
Due to its public nature, the Ethereum Polygon DID doesn't support private profiles.
Revocation Status
Mobile applications can get the Revocation Status of a particular credential by requesting that information straight from the Issuer Node. However, if the Issuer Node is offline for some reason, that communication would not work. The Reverse Hash Service and the On-chain Revocation Status are two solutions for this issue.
Reverse Hash Service
The Reverse Hash Service (RHS) stores all the revocation information online which can be accessed by mobile applications and verifiers. In this scenario, the communication between mobile and Reverse Hash Service replaces the link between the application and the Issuer Node:
As the diagram shows, the Issuer Node sends the revocation information to the RHS. The service, then, is able to return the credential status to the application.
On-chain Revocation
On-chain Revocation status leverages the blockchain decentralized storage to make the revocation information permanent on the network. That means that, even if the Issuer Node or the Reverse Hash Service is down, the data is still available on-chain.
Non-merklized credentials
Non-merklized credentials are specially important for on-chain issuers, because smart contracts built on Solidity can't fetch JSON-LD schemas directly via HTTP or IPFS.
Here is an example of a non-merklized schema. Compare it to this merklized one. Notice that the schema is defined by utilizing an iden3_serialization attribute.
Read more about non-merklized credentials on the Iden3 documentation.