Credential registry readme (#334)

* Move credential registry description into README.md

* Compare README in the CI

* Move section header in README

* Set munimum Rust version to 1.66 in concordium-std

.github/workflows/linter.yml

@@ -12,7 +12,7 @@ name: Clippy & fmt
 
 env:
   RUST_FMT: nightly-2023-04-01
-  RUST_VERSION: "1.65"
+  RUST_VERSION: "1.66"
 
 
 jobs:
@@ -352,6 +352,7 @@ jobs:
           sed -i "s/version = \"5.0\", default-features = false/path = \"..\/..\/concordium-cis2\", version = \"5.0\", default-features = false/g" ${{ runner.temp }}/$PROJECT_NAME/Cargo.toml
           diff ${{ runner.temp }}/$PROJECT_NAME/Cargo.toml examples/credential-registry/Cargo.toml
           diff ${{ runner.temp }}/$PROJECT_NAME/src/lib.rs examples/credential-registry/src/lib.rs
+          diff ${{ runner.temp }}/$PROJECT_NAME/README.md examples/credential-registry/README.md
 
   clippy-cis2:
     name: Clippy

concordium-std/CHANGELOG.md

@@ -2,6 +2,8 @@
 
 ## Unreleased changes
 
+- Set minimum Rust version to 1.66.
+
 ## concordium-std 8.0.0 (2023-08-21)
 
 - Support adding attribute `#[concordium(repr(u))]` for enum types, where `u` is either `u8` or `u16`. Setting this changes the integer serialization used for the variant tags in derive macros such as  `Serial`, `Deserial`, `DeserialWithState` and `SchemaType`.

concordium-std/Cargo.toml

@@ -3,7 +3,7 @@ name = "concordium-std"
 version = "8.0.0"
 authors = ["Concordium <[email protected]>"]
 edition = "2021"
-rust-version = "1.65"
+rust-version = "1.66"
 license = "MPL-2.0"
 description = "A standard library for writing smart contracts for the Concordium blockchain in Rust."
 homepage = "https://github.com/Concordium/concordium-rust-smart-contracts/"

examples/credential-registry/README.md

@@ -0,0 +1,47 @@
+# Credential registry contract
+
+This smart contract implements an example on-chain registry for the public
+part of verifiable credentials (VCs). The contract follows CIS-4: Credential
+Registry Standard.
+
+The contract keeps track of credentials' public data, allows managing the
+VC life cycle. and querying VCs data and status. The intended users are
+issuers of VCs, holders of VCs, revocation authorities, and verifiers.
+
+When initializing a contract, the issuer provides a type and a schema
+reference for the credentials in the registry. The schema reference points
+to a JSON document describing the structure of verifiable credentials in the
+registry (attributes and their types). If the issuer wants to issue
+verifiable credentials of several types, they can deploy several instances
+of this contract with different credential types.
+
+## Issuer's functionality
+
+- register/remove revocation authority keys;
+- register a new credential;
+- revoke a credential;
+- update the issuer's metadata;
+- update the credential metadata;
+- update credential schema reference;
+- upgrade the contract, set implementors;
+- restore (cancel revocation of) a revoked credential.
+
+## Holder's functionality
+
+- revoke a credential by signing a revocation message.
+
+## Revocation authority's functionality
+
+Revocation authorities are some entities chosen by the issuer that have
+revocation capabilities. Their public keys are registered by the issuer and
+a revocation authority signs a revocation message with the corresponding
+private key.
+
+- revoke a credential by signing a revocation message.
+
+## Verifier's functionality
+
+- view credential status to verify VC validity;
+- view credential data to verify proofs (verifiable presentations) requested
+  from holders.
+

examples/credential-registry/src/lib.rs

@@ -1,49 +1,4 @@
-//! This smart contract implements an example on-chain registry for the public
-//! part of verifiable credentials (VCs). The contract follows CIS-4: Credential
-//! Registry Standard.
-//!
-//! # Description
-//!
-//! The contract keeps track of credentials' public data, allows managing the
-//! VC life cycle. and querying VCs data and status. The intended users are
-//! issuers of VCs, holders of VCs, revocation authorities, and verifiers.
-//!
-//! When initializing a contract, the issuer provides a type and a schema
-//! reference for the credentials in the registry. The schema reference points
-//! to a JSON document describing the structure of verifiable credentials in the
-//! registry (attributes and their types). If the issuer wants to issue
-//! verifiable credentials of several types, they can deploy several instances
-//! of this contract with different credential types.
-//!
-//! ## Issuer's functionality
-//!
-//! - register/remove revocation authority keys;
-//! - register a new credential;
-//! - revoke a credential;
-//! - update the issuer's metadata;
-//! - update the credential metadata;
-//! - update credential schema reference;
-//! - upgrade the contract, set implementors;
-//! - restore (cancel revocation of) a revoked credential.
-//!
-//! ## Holder's functionality
-//!
-//! - revoke a credential by signing a revocation message.
-//!
-//! ## Revocation authority's functionality
-//!
-//! Revocation authorities are some entities chosen by the issuer that have
-//! revocation capabilities. Their public keys are registered by the issuer and
-//! a revocation authority signs a revocation message with the corresponding
-//! private key.
-//!
-//! - revoke a credential by signing a revocation message.
-//!
-//! ## Verifier's functionality
-//!
-//! - view credential status to verify VC validity;
-//! - view credential data to verify proofs (verifiable presentations) requested
-//!   from holders.
+#![doc = include_str!("../README.md")]
 use concordium_cis2::*;
 use concordium_std::*;
 

templates/credential-registry/README.md

@@ -0,0 +1,47 @@
+# Credential registry contract
+
+This smart contract implements an example on-chain registry for the public
+part of verifiable credentials (VCs). The contract follows CIS-4: Credential
+Registry Standard.
+
+The contract keeps track of credentials' public data, allows managing the
+VC life cycle. and querying VCs data and status. The intended users are
+issuers of VCs, holders of VCs, revocation authorities, and verifiers.
+
+When initializing a contract, the issuer provides a type and a schema
+reference for the credentials in the registry. The schema reference points
+to a JSON document describing the structure of verifiable credentials in the
+registry (attributes and their types). If the issuer wants to issue
+verifiable credentials of several types, they can deploy several instances
+of this contract with different credential types.
+
+## Issuer's functionality
+
+{% if revocable_by_others %}- register/remove revocation authority keys;{% else %}{% endif %}
+- register a new credential;
+- revoke a credential;
+- update the issuer's metadata;
+- update the credential metadata;
+- update credential schema reference;
+{% if restorable %}- upgrade the contract, set implementors;
+- restore (cancel revocation of) a revoked credential.{% else %}- upgrade the contract, set implementors.{% endif %}
+
+## Holder's functionality
+
+- revoke a credential by signing a revocation message.
+{% if revocable_by_others %}
+## Revocation authority's functionality
+
+Revocation authorities are some entities chosen by the issuer that have
+revocation capabilities. Their public keys are registered by the issuer and
+a revocation authority signs a revocation message with the corresponding
+private key.
+
+- revoke a credential by signing a revocation message.{%endif%}
+
+## Verifier's functionality
+
+- view credential status to verify VC validity;
+- view credential data to verify proofs (verifiable presentations) requested
+  from holders.
+

templates/credential-registry/src/lib.rs

@@ -1,49 +1,4 @@
-//! This smart contract implements an example on-chain registry for the public
-//! part of verifiable credentials (VCs). The contract follows CIS-4: Credential
-//! Registry Standard.
-//!
-//! # Description
-//!
-//! The contract keeps track of credentials' public data, allows managing the
-//! VC life cycle. and querying VCs data and status. The intended users are
-//! issuers of VCs, holders of VCs, revocation authorities, and verifiers.
-//!
-//! When initializing a contract, the issuer provides a type and a schema
-//! reference for the credentials in the registry. The schema reference points
-//! to a JSON document describing the structure of verifiable credentials in the
-//! registry (attributes and their types). If the issuer wants to issue
-//! verifiable credentials of several types, they can deploy several instances
-//! of this contract with different credential types.
-//!
-//! ## Issuer's functionality
-//!
-{% if revocable_by_others %}//! - register/remove revocation authority keys;{% else %}//!{% endif %}
-//! - register a new credential;
-//! - revoke a credential;
-//! - update the issuer's metadata;
-//! - update the credential metadata;
-//! - update credential schema reference;
-{% if restorable %}//! - upgrade the contract, set implementors;
-//! - restore (cancel revocation of) a revoked credential.{% else %}//! - upgrade the contract, set implementors.{% endif %}
-//!
-//! ## Holder's functionality
-//!
-//! - revoke a credential by signing a revocation message.
-//!{% if revocable_by_others %}
-//! ## Revocation authority's functionality
-//!
-//! Revocation authorities are some entities chosen by the issuer that have
-//! revocation capabilities. Their public keys are registered by the issuer and
-//! a revocation authority signs a revocation message with the corresponding
-//! private key.
-//!
-//! - revoke a credential by signing a revocation message.{%endif%}
-//!
-//! ## Verifier's functionality
-//!
-//! - view credential status to verify VC validity;
-//! - view credential data to verify proofs (verifiable presentations) requested
-//!   from holders.
+#![doc = include_str!("../README.md")]
 use concordium_cis2::*;
 use concordium_std::*;