Authors Andre Kudra*, Torsten Lodderstedt, Paul Bastian, Mirko Mollik, Maaike van Leuken, Caspar Roelofs. Abstract In this paper, a comparison matrix for the wide variety of credential formats - such as W3C Verifiable Credentials, AnonCreds, ISO-standard Mobile Driving License (mDL) - and the various related signing algorithms, revocation mechanisms, and key management systems (collectively referred to as credential profiles) is introduced. The credential profile comparison matrix is a living document that serves as an accessible resource for an in-depth evaluation of the technical requirements and their technical and non-technical implications for different use-cases and objectives. This paper introduces the rationale behind this matrix, the various properties that are included in the matrix and their definitions, and serves as an application guide on how to use the matrix for more informed technical and non-technical discussions and decision making.

Summary The state of the trustchain ledger is stored in a Patricia Merkle trie and represents the state of all parsed DID resources. By signing the state root along with a timestamp by multiple validators, it is possible to verify that a particular DID resource is included in the state trie and is therefore part of the ledger. The signed state is stored periodically and allows to work with verified previous states of the ledger to request older DID version and guarantee freshness. Motivation To validate verifiable credentials (VC), the verifier may not need to request the issuer's latest DID document, but rather those at the time the credential was issued, as the issuer's signing keys may have changed over time. This problem occurs because some objects represented as DID documents are mutable, so they can change their state over time (e.g. due to key rotation, adding new fields, etc.). When the object is immutable, it is trivial for the ledger to provide a verifiable response. However, if the object is mutable, there is no trivial way for the ledger to provide a verifiable response of an object's state in the past. The state proof allows for a mechanism to validate every version in the history of an object.

Development Both projects are open source Indy: community based amount is very limited no paid developers