Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

peer did 2/3 resolution #2472

Merged

Conversation

Jsyro
Copy link
Contributor

@Jsyro Jsyro commented Sep 6, 2023

First component to final solution for #2249.

Add resolution capabilities for did:peer:2 and did:peer:3, as well as did:peer:3 creation methods.

@Jsyro Jsyro added the enhancement New feature or request label Sep 6, 2023
Signed-off-by: Jason Syrotuck <[email protected]>
Signed-off-by: Jason Syrotuck <[email protected]>
Signed-off-by: Jason Syrotuck <[email protected]>
aries_cloudagent/connections/base_manager.py Outdated Show resolved Hide resolved
aries_cloudagent/connections/base_manager.py Outdated Show resolved Hide resolved
Comment on lines +68 to +86
def _resolve_peer_did_with_service_key_reference(
peer_did_2: Union[str, DID]
) -> DIDDocument:
try:
doc = resolve_peer_did(peer_did_2)
## WORKAROUND LIBRARY NOT REREFERENCING RECEIPIENT_KEY
services = doc.service
signing_keys = [
vm
for vm in doc.verification_method or []
if vm.type == "Ed25519VerificationKey2020"
]
if services and signing_keys:
services[0].__dict__["recipient_keys"] = [signing_keys[0].id]
else:
raise Exception("no recipient_key signing_key pair")
except Exception as e:
raise ValueError("pydantic validation error:" + str(e))
return doc
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This workaround is painful but given that peer did creators won't necessarily generate the same ids for their verification methods that our library does (since it's not defined in the spec) means we can't avoid this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea.... it's jank.. but because it's from a peer_did we know exactly what transformation needs to happen.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sicpa-dlab/peer-did-python#63

I also opened an issue in the peer-did-python library pointing out my need for this workaround.

aries_cloudagent/resolver/default/peer2.py Outdated Show resolved Hide resolved
Comment on lines 128 to 149
async def _add_key_for_did(profile, did: str, key: str):
"""Store a verkey for lookup against a DID.

Args:
did: The DID to associate with this key
key: The verkey to be added
"""
record = StorageRecord(
BaseConnectionManager.RECORD_TYPE_DID_KEY, key, {"did": did, "key": key}
)
async with profile.session() as session:
storage: BaseStorage = session.inject(BaseStorage)
try:
await storage.find_record(
BaseConnectionManager.RECORD_TYPE_DID_KEY, {"key": key}
)
except StorageNotFoundError:
await storage.add_record(record)
except StorageDuplicateError:
pass
# "Key already associated with DID: %s; this is likely caused by "
# "routing keys being erroneously stored in the past",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method is a copy paste from the base connection manager. While I recommended not leaving doc storage and retrieval to the base connection manager, I would recommend leaving the key -> did -> connection management to the base connection manager.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it appropriate to instantiate an instance of the base manage to call these methods. I wasn't sure if that would look weirder. easy enough change to make if that is the preferred separation of concerns

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think instantiating an instance of the base connection manager is acceptable. I think it's better to have the explicit dependency than the implicit one we have by writing to the same records in the wallet.

aries_cloudagent/resolver/default/peer3.py Outdated Show resolved Hide resolved
Signed-off-by: Jason Syrotuck <[email protected]>
Signed-off-by: Jason Syrotuck <[email protected]>
Signed-off-by: Jason Syrotuck <[email protected]>
Signed-off-by: Jason Syrotuck <[email protected]>
Signed-off-by: Jason Syrotuck <[email protected]>
Signed-off-by: Jason Syrotuck <[email protected]>
@sonarqubecloud
Copy link

sonarqubecloud bot commented Sep 7, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

@swcurran swcurran merged commit 9aa7334 into openwallet-foundation:main Sep 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants