search

openwallet-foundation / acapy

ACA-Py is a foundation for building decentralized identity applications and services running in non-mobile environments.
https://aca-py.org
Apache License 2.0
420 stars 513 forks source link

Review/align proposed Community Coordinated Update for Peer DIDs with ACA-Py work #2360

Closed swcurran closed 11 months ago

swcurran commented 1 year ago

Review the proposed Unqualified to Qualified DIDs Community Coordinated Update and especially the DIDDoc to did:peer:3 conversion routine (currently here) to see if it (a) matches what we are doing in ACA-Py, and (b) covers all of the “other cases” of DIDDocs in the unit/integration tests.

At minimum, the conversion routine needs to add “publicKey” as a synonym for “verificationMethod” in the algorithm, right?

swcurran commented 1 year ago

From Disocrd by @Jsyro :

I'm working on updating acapy to support did:peer:2, included in that is updating the DIDDoc class which pre-dates the DIF Specification to be compliant.

Draft PR: https://github.com/hyperledger/aries-cloudagent-python/pull/2353

The general approach is prior to deserialization, it goes through the dict and updates the members and structure to be complaint before passing it to pydid's DIDDocument deserializer, pydid's class correctly enforces and expects that up to date specification.

There is a suite a test cases that have a very broad range of obsolete (are now out of date/but may have been acceptable at the time), updating my conversion method to convert all of the invalid payloads to valid ones would be quite a task. @swcurran @andrewwhitehead @dbluhm

I want to know if the community has any known examples of these obsolete DIDDocuments that may exist in acapy agents today that I would NEED to be handled/made compliant, or potentially to invalidate the existing did_document in storage and tell the target of the connection that the previous did document is 'now invalid' and it needs to send a new one.

The existing test suite of did document dictionaries. https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/connections/models/diddoc/tests/test_diddoc.py

swcurran commented 1 year ago

In scanning the list, I think all are valid DIDDocs, other than the known incompatibility of "PublicKey" instead of VerificationMethod. I think the algorithm that Timo defined in his proposal (linked in the issue) will handle all of these -- with the exception of a fully populated get_hashcode_codec(publicKey, keyType) routine. If we are calling a library for that -- all good. Worst case, we would need to add that call, and add to it as needed.

I don't think it would be a bad thing to follow (or define) a reference implementation of Timo's algorithm for processing any unqualified DIDDoc.

@JSyro -- let me know what you think after looking at Timo's proposed approach.