indy-node icon indicating copy to clipboard operation
indy-node copied to clipboard

Update default auth_rules to reflect deprecation of ATTRIB

Open lynnbendixsen opened this issue 3 years ago • 4 comments

As a message to those creating new networks that the ATTRIB functionality is being removed from indy-node I suggest that we change the default auth_rules table to mark ATTRIB transactions as FORBIDDEN.

Currently the default auth_rules give some permissions to those that would like to perform ATTRIB transactions. Changing it to FORBIDDEN would make it so that, by default, a user would no longer be able to perform an ATTRIB transaction, thus demonstrating that ATTRIB has been deprecated. The setting of FORBIDDEN can easily be reverted to the previous default value, if desired, so that a new network can still allow ATTRIB transactions as needed for backward compatibility. (I tested changing a value that defaults to FORBIDDEN to a different value and then back and all worked well).

Again, this suggestion is only to change the default value of ATTRIB transactions in the auth_rule table. This will not affect upgrading existing networks, nor will it change anything except the default value (which is still alterable, if desired).

lynnbendixsen avatar Feb 15 '22 17:02 lynnbendixsen

To be a little clearer, when did:indy is deployed, ATTRIB will be considered deprecated, and may be removed in future updates to indy-node.

swcurran avatar Feb 15 '22 17:02 swcurran

Is there a link to some documentation for those interested in the decision driving this change and the recommended migration/alternative?

WadeBarnes avatar Feb 15 '22 17:02 WadeBarnes

This is driven by the use of the did:indy DID method -- https://hyperledger.github.io/indy-did-method/

A PR is being added to that about deprecation - we have a DCO issue on that.

Basically - there is only one convention that uses ATTRIB -- endpoint -- to be added to the DIDDoc for the DID. When the did:indy changes are complete, there will be full support for DIDDocs, with the data for the DIDDoc (including endpoint) going directly in the NYM (DID). As such, there will be no need for ATTRIBs, and no need to read the ledger twice to resolve a DID. For backwards compatibility, a resolver will still have to try to get the endpoint ATTRIB if there is no diddocContent in the NYM/DID object. DID Controllers are encouraged to use the new approach as soon as possible to eliminate the older, double-read approach.

swcurran avatar Feb 15 '22 17:02 swcurran

As @swcurran, states, this will be cleaner once did:indy is fully deployed.

WadeBarnes avatar May 23 '23 15:05 WadeBarnes