swcurran
commented
2 years ago 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.
Open lynnbendixsen opened 2 years ago
swcurran
commented
2 years ago 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.
WadeBarnes
commented
2 years ago Is there a link to some documentation for those interested in the decision driving this change and the recommended migration/alternative?
swcurran
commented
2 years ago 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.
WadeBarnes
commented
1 year ago As @swcurran, states, this will be cleaner once did:indy is fully deployed.
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).