-
Notifications
You must be signed in to change notification settings - Fork 516
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
peer did 2/3 resolution #2472
Conversation
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]>
… feature/peer-did-resolution
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]>
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]>
… feature/peer-did-resolution
Signed-off-by: Jason Syrotuck <[email protected]>
Signed-off-by: Jason Syrotuck <[email protected]>
… feature/peer-did-resolution
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]>
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also opened an issue in the peer-did-python library pointing out my need for this workaround.
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", |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
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]>
Signed-off-by: Jason Syrotuck <[email protected]>
Signed-off-by: Jason Syrotuck <[email protected]>
Signed-off-by: Jason Syrotuck <[email protected]>
… feature/peer-did-resolution
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]>
Kudos, SonarCloud Quality Gate passed! |
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.