Integration of Identity Verification as optional Add-on

Circles general
1

Identity Verification as optional “Add-on”

For several use cases, the integration of an external Identity Verification Service makes sense. Even though with Circles UBI, the main means of identifying users is by their social graph, this sometimes does not work well.

For example, a cloud service provider would have difficulties selling his services to unknown (not necessarily untrusted) users which are not in her local group or “few-hops” social graph network.

For these “B2B”-use-cases, other augmenting identity verification mechanisms add value. For more financial use cases, even KYC/AML might be necessary. So having pluggable Identity Verification Services makes sense for Circles.

Integration of Fractal Credentials

Fractal offers two kind of integrations:

  • Fractal Wallet (Browser Extension)
  • Fractal ID (OAuth2 Authorization Code Flow)

Fractal Wallet

Fractal Wallet is a browser extension which is completely web3-compliant. The big advantage for Circles is that no server side processing is needed. The complete OAuth2 flow is executed on Fractal side, therefore only client-side integrations (web3.js/fractal.js) is necessary.
An obvious disadvantage is the dependency on a browser extension.

Fractal ID Authorization Code Grant Flow

For the Fractal ID Authorization Code Grant Flow, several components are involved. The communication sequence between the components is described here:

enter image description here
enter image description here1138×546 37.9 KB

With this option, the user does not have to install a browser extension. However, the flow is more complex in implementation and a (centralized) server component is necessary, so clearly there is a trade-off.

References

2 Likes
2

Currently, de-duplication (to prevent that people register two different addresses, ie. proof-of-uniqueness) is not implemented by Fractal. However, for a first iteration, it might be enough to use attributes of the Fractal response:

Response sample for “person” data:

"person": {
    "date_of_birth": "1967-08-16",
    "full_name": "David Muller",
    "identification_document_country": "DE",
    "identification_document_front_file": "<URL>",
    "identification_document_number": "123456789",
    "identification_document_selfie_file": "<URL>",
    "identification_document_type": "passport",
    "place_of_birth": "Berlin",
    "residential_address": "Wiener Straße 10, Berlin, 10999",
    "residential_address_country": "DE",
    "residential_address_proof_file": "<URL>",
    "wallet_address": "0xa1eD7e13271bFeB758CB5CB6F3EdcC97A0E5943D",
    "wallet_currency": "ETH"
  }

with eg. birthdate, full name and identification_document_number (maybe combined with a specific document_type to prevent double nationalities) a “unique enough” dataset can be derived for some address. What we could do with this:

  • Use the hashed value as input value on address (member) registration and as a key for a map with the address, so one registration is possible for the hash only - but this is relying on an external hashing method
  • Use the fields as input and hash in the smart contract itself (this might be GDPR problematic)
  • Use a separate smart contract which handles registration (and can implement one of the methods above) and only this contract is allowed to add members

With this, a quite stable proof-of-uniqueness check is possible before adding members which are allowed to use a Group Currency.

3

In branch fractal there is a working Fractal integration prototype: https://github.com/ice09/fractal-circles-integration/tree/fractal

Feel free to comment. The version uses the GroupCurrencyToken of this Circles-Fork: https://github.com/ice09/circles-contracts/tree/master/contracts