CIP Proof Ownership for Stake Address

Developers CIPs
1

Hi,

I am currently developing a CIP to proof the ownership of stake address.
Let’s assume I want to prove my ownership of a stake address as an optional mechanism - what is currently considered the best practice.
Let’s assume I have a proved Decentralized Identifier I would imagine proving the ownership of the wallet with a transaction where the metadata is signed by the:

  • private key related to my DID document.
  • payment.skey
  • stake.skey

The metadata itself should look something like:

{
    "stakeAddressOwnership" : {
        "ownership": {
            "stakeaddress": "<stakeadress>",
            "ownerDID": "<ownerDID>"
        },
        "signatures": {
            "ownerSignature": "<CBOR representation of ownership signed by ownerDID provate key>",
            "paymentSignature": "<ownerSignature signed by payment.skey>",
            "stakeAdressSignature": "<paymentSignature signed by stake.skey>"
        }
    }
}

Any thoughts on that or similar reference implementations?

2

CIP7 message signing might come in handy here:

3

Can we already get decentralised identifiers somewhere?

Otherwise, it’s perhaps a little early to settle on something that has no working implementation in the wild, let alone authorities supporting it. (Without authorities, we are back at square one: How do we prove that the DID belongs to the real person? Some strange self-organised, decentralised mumbo-jumbo could certify anyone to be anything.)

1 Like
4

We are working on the DID part currently at IAMX.ID. The DIDs will be fullfill European KYC standards if demanded by the holder.
But for other cases like i.e. the stake address of an NGO KYC might be optional.

But we should have a standard on how to prove a wallet ownership.

1 Like
5

Thanks! Looks interesting. After the ID Wallet App disaster in Germany, I’m kind of skeptical for mass adoption of blockchain technology for these use cases. (And CCC is right: They are not really necessary.)

Fair enough.

Regarding the details of your proposal:

You only speak of stake addresses, here, but:

You want a signature by a payment key, here. Which payment key? There are dozens in a wallet, one for each address.

If you only want to verify the relationship between a stake address and a DID, signature by the stake key should be enough.

If you want to verify relationship to an address (or several of them?), signature by the payment key is probably enough, but you could also include signature by the stake key.

(Though not all addresses have an associated stake key. Do you want to have ownership proofs for them also?)

Related problem: According to https://www.w3.org/TR/did-core/#verification-methods, there may be many verification methods registered in a DID document.

Don’t you need a more specific ID choosing, which of them to use? Or maybe even the possibility to use multiple methods in case an application decides to only support a few from the zoo?

1 Like
6

How interesting! I would like to do something somewhat similar. I would like for an organisation like the red cross to prove that a certain address belongs to them using a digital certificate. Turns out these certificates are not very valuable and that a scammer could could get one albeit woth some difficulty. I guess it would work if the IRS should decide to become a Certificate Authority. They would make sure a bill would be passed that made it mandatory, at least for some.

Anyway, please elaborate. If I want to stake ada using that address, how would I know, what would it say? I suppose the wallet should be aware of this somehow. Or should ai use a blockchain explorer?

7

Hello @jochen

Couldn’t you reuse alsoKnownAs instead of stakeAddressOwnership to add a stake address as an identifier?

If one assumes that all prerequisites for DID are there to be fully trusted, then adding any wallet/stake address under asloKnownAs would instantly qualify it as verified since the protocol is already in place.

8

Is alsoKnownAs a reference to a CIP ? I think I don’t understand the context.

9

It’s a reference to Decentralized Identifier.
Quote:
" 5.1.3 Also Known As

A DID subject can have multiple identifiers for different purposes, or at different times. The assertion that two or more DIDs (or other types of URI) refer to the same DID subject can be made using the alsoKnownAs property.

alsoKnownAs

The alsoKnownAs property is OPTIONAL . If present, the value MUST be a set where each item in the set is a URI conforming to [RFC3986].

This relationship is a statement that the subject of this identifier is also identified by one or more other identifiers."

Source:

If we are assuming that you have a proved Decentralized Identifier, why not just use tools already available. This way attaching a staking key becomes part of DID under alsoKnownAs, thus your DID becomes proof for your alsoKnownAs which becomes your stake key.

I’m just brainstorming ideas here. Consider this feed back as repurpose vs. new protocol line of thought.