Blockstream / asset_registry

registry for liquid assets
5 stars 2 forks source link

FR: Eliminate registry entry #3

Open alessandro-saglimbeni opened 4 years ago

alessandro-saglimbeni commented 4 years ago

Problem

Issuers can only register a new asset to the asset registry but they cannot eliminate an entry of theirs.

This might be necessary if the name, ticker or precision are wrong, because currently only one asset_id can be registered with a given name or ticker or precision with a certain issuer_domain

Requirement

Allow issuers to eliminate an entry of theirs from the registry, provided that:

greenaddress commented 4 years ago

Seems reasonable to me.

The signed message should contain the asset id at minimum.

shesek commented 4 years ago

Do we want to keep around some record indicating that this asset was registered in the past (apart from git the history)? We could use that information to issue a more descriptive 410 Gone, or perhaps even make the deleted asset json still available somehow (but without taking up ticker namespace).

alessandro-saglimbeni commented 4 years ago

some record indicating that this asset was registered in the past

This sounds to me more like a "deprecate" functionality, which is useful, but my understanding for this requirement is straight elimination of an entry, before the asset is actually widely distributed, mostly for issuances made by mistake.

I'd track the "deprecation" separately because that'd also require Registry clients to be aware of deprecated assets, and probably see the old information along with some warning label probably.

@allenpiscitello what's your take?

shesek commented 4 years ago

before the asset is actually widely distributed, mostly for issuances made by mistake.

If issuers can self-eliminate their asset from the registry, we couldn't enforce that this is what its being used for... we need to consider that this could delete widely used assets as well.

Also, if we do keep some record of the deletion, another thing that we might want to persist is the digital signature used to authorize it.

shesek commented 4 years ago

Do we want to do some kind of challenge-response, have the issuer sign over some nonce or maybe a recent timestamp?

shesek commented 4 years ago

Should we prevent deleted issued from being re-registered?

shesek commented 4 years ago

the asset proof has been removed from the .well-known directory under the previously registered domain

Should we only consider 404 replies from the asset domain server as a verification that the proof was removed, or should we accept any failure (the server is down, the domain name does not resolve, there's no internet on our side, etc) as a verification?

On the one hand, demanding a valid 404 reply from the asset domain server would mean that its not possible to remove assets if you no longer control the domain name, say if the issuer let it expire.

On the other hand, treating any connection error as a removal verification would mean that if the asset server is temporarily down or our internet is temporarily not working, we would wrongly think that the proof was removed while in fact its still there. We will still have the signature as a verification, so I guess it wouldn't be too terrible?

greenaddress commented 4 years ago

I think users should make a message like

"remove $asset_id from registry"

I don't think we even need to check that the asset was removed from the server, they could add it 3 mins later if they wanted to and we can side step the issues you mentioned of timeout, domain expiry and dns resolving etc

We do not need to keep a record of deleted entries (other than git) nor we should forbid re-registering of them.

shesek commented 4 years ago

I don't think we even need to check that the asset was removed from the server

I agree, it doesn't really tell us that much and the signature already provides a strong form of authentication.

We do not need to keep a record of deleted entries (other than git)

I'll keep the digital signature as part of the git commit message that removes the asset from the db.

shesek commented 4 years ago

Implemented in https://github.com/Blockstream/asset_registry/commit/4c064b25973a418c0db053d4c364edf0279ee27f, https://github.com/Blockstream/asset_registry/commit/2bcbcfef6bd95f1e87ad6118ecc3623e6d23de55 & https://github.com/Blockstream/asset_registry/commit/9b072e1a5a26dd1eadc8d120ecb963dee29fc0bd, unit tests added in https://github.com/Blockstream/asset_registry/commit/f27107e5d212941377fbdb84433afe6ff3b20429.

Will keep this issue open until its deployed and tested on the live server.

shesek commented 4 years ago

The changes are live and I successfully deleted a test asset on the live server.

To delete an asset, the issuer needs to sign the message "remove <asset-id> from registry" and make the following HTTP DELETE request:

$  curl -X DELETE https://assets.blockstream.info/<asset-id> \
    -H 'Content-Type: application/json' \
    --data '{"signature":"<base64-encoded-signature>"}'
shesek commented 4 years ago

Do we want to do some kind of challenge-response, have the issuer sign over some nonce or maybe a recent timestamp?

Should we prevent deleted issued from being re-registered?

@greenaddress Note that answering "no" on these two questions means that if the issuer re-registers a deleted asset, anyone who gets hold of the old deletion signature (say, from the git history) can delete it from the registry again.

Also, if an issuer deletes an asset without removing the domain link proof, there's nothing preventing a third party from re-registering the asset to the registry by submitting the original json contract again.