Skip to content

Attestation Service 1.1.0
Compare
Choose a tag to compare
@timmoreton timmoreton released this 27 Oct 23:04
attestation-service-v1.1.0
b948ed0
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

This is a feature release for all validators.

Documentation

Full documentation is here.

Upgrading

Validator operators are advised to test first on Baklava before deploying changes on Mainnet.

Deploy the Docker image identified as follows:

  • us.gcr.io/celo-testnet/celo-monorepo:attestation-service-v1.1.0
  • us.gcr.io/celo-testnet/celo-monorepo@sha256:7c5791c69b16f1f727e9b708828ea6fb7e1be1c236b22e89049b09b427d1c306

Existing configurations should work as is. New configuration options are described in the documentation.

Changes

Support for security codes

Attestation Service 1.1.0 adds support for security codes. This entails no operational changes.

For clients, the flow is as follows:

  • Client calls the /attestations endpoint with a securityCodePrefix parameter (whose value is a single digit number intended to allow the client to disambiguate different senders) and an optional language parameter.
  • Attestations Service then sends an SMS with an explanation in the requested language, the security code prefix and a random 7 digit security code, concatenated to appear as a single 8 digit numeric code. The SMS does not include the full signed attestation message.
  • The client receives the SMS, extracts the prefix to determine which Attestation Service sent it, then passes the remainder of the code in the securityCode parameter to the /get_attestations endpoint. If the security code supplied is as recorded, the attestation service response will include the signed attestation message.

Other changes

  • Fixed an issue where if the Celo node fails and is restarted, the connection to the node was not always re-established.
Assets 2
Loading