GPG/WoT-like identities with LNP/BP

[dr-orlovsky]

For publishing RGB schema, smart contracts, assets etc we need to adopt some system for developer/issuers identity and signatures, which can be verified by the users and wallet devs against those identities. While we can leverage existing systems, they have a drawbacks with RGB and LNP/BP able to address them; thus I have started working on leveraging what RGB and LNP/BP can do.

RGB enables more advanced and decentralized WoT-like identity management, which could be better than PGP/GPG in at least two aspects:

• key revocations are globally seen (via single-use-seal closings) by anybody knowing about the identity;
• it is possible to prove the fact that a signagure was created using a key which was not revoked at the time of the signature;
• no centralized key servers requred; decentralized Storm over LN can be used instead.

At the same time RGB provides a standard way for working with identity metadata used by PGP/GPG: it may store names, photos etc in the metadata fields of the contract; it may link identities together and prove that links etc, so functionality added by RGB to the decentralized identities is clearly additive.

Before leveraging what RGB can give to a decentralized identity, there are things which can be improved with "pure" LNP/BP, without single-use-seals or RGB use. Specifically, we may start using secp256k1 keys derived from the wallet seed for identity and message signatures (this elliptic curve is not yet supported by PGP/GPG). While without full PGP/GPG key management (revocation, metadata, keyservers) using secp keys for identities/message sigs/encryption is not advisable, the perspective of leveraging RGB later provides a rationale to start adopting this curve for the decentralized identities already.

A good starting point can be an LNP/BP standard defining EC-based identities which can be used by RGB later.

It may support multiple elliptic curves, different signature schemes with each curve and multiple forms of encodings. Together, they constitute algorithm triple, like secp256k1-bip340-xonly. Initially I plan to support Secp246k1 and Edward25519 curves, Schnorr and Ed signatures.

An identity is a certificate composed of a public key and a signature over the hash of the public key, proving ownership of the private key (to prevent fake identities). It can be bech32m-encoded using crt prefix and contain a guard (see https://github.com/orgs/LNP-BP/discussions/134), which represents a readable nym (or fingerprint) of the identity¹.

Signatures, created with identity certificate over certain message will also be represented as a bech32m strings, starting with sig prefix. The signature information must also contain a hashing algorithm used for committing to the message data.

Examples:

LNP/BP identity certificate:
crt1qyghn0nx0muaewav2ksx99wwsu9swq5mlndjmn3gm9vl9q2mzmup0xrdgswg9ate53t5hvppkl2xjem0y2sg5r738s7jqdlk4jd49v72c4t0f7e3a2yup6xhldv4c35hf5ncvas3r8ulwf4xx3ynqy3vwsc37avgyrl_game_accent_candle

Fingerprint (identity name): 8wdwat_game_accent_candle

Certificate data (printed out like with GPG):

$ lnpbp identity crt1qyghn0nx0muaewav2ksx99wwsu9swq5mlndjmn3gm9vl9q2mzmup0xrdgswg9ate53t5hvppkl2xjem0y2sg5r\
                 738s7jqdlk4jd49v72c4t0f7e3a2yup6xhldv4c35hf5ncvas3r8ulwf4xx3ynqy3vwsc37avgyrl_game_accent_candle

nym   game_accent_candle_avgyrl
alg   secp256k1-bip340-xonly
idk   79be 667e f9dc bbac 55a0 6295 ce87 0b07 029b fcdb 2dce 28d9 59f2 815b 16f8 1798
sig   e4b4 1a37 317e 1de6 bd00 ec17 fcb6 940a cda0 5a21 586c 3134 b793 c0c2 d89f 8e09
      2efc c7af 9829 78a0 9f19 8040 e680 66e2 859c 4a8e 8036 2d4e e659 5333 388e 6949

Signature: sig1qgq3z7kp70wmjtjn2p0rvh4ahpky6j3yvzyezqzs60rwgdc7asnx55y4r2y5m4dfqpp2x9vg08epdmpw38jey4mkagnc2f09qhl87n0mh5usxaxp9j

Reference implementation

I already created a draft PR implementing most of the proposal: LNP-BP/rust-lnpbp#223

Footnotes

1. It is advised to extend the guard with the last 6 characters of the bech32 string (as shown in the sample) to protect from attackers which can mine for a key having the same CRC32 sum as some other key. ↩

[dr-orlovsky]

Digital identity components:

• LNP/BP Identity certificate file
• RGB DID consignment (after RGB22 standard)

LNP/BP identity certificate proves ownership of a public key. Public key may be created with different elliptic curves. The list of currently supported curves:

• Secp256k1
• Edwards25519

LNP/BP identity certificate is a bech32m-encoded string starting with crt HRP. It contains information about

• The used curve (1 byte)
• The sign algorithm for the curve (4 bits)
• The used public key and signature compression algorithm (4 bits)
• Public key
• Signature

The certificate may be also come with a three word mnemonic to ensure human-readable identity and verification of the data encoded in bech32 format regarding checksum mining attacks.