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

Cannot resolve peer did with encryption entry of authentication. #49

Open
Jsyro opened this issue Jun 14, 2023 · 3 comments
Open

Cannot resolve peer did with encryption entry of authentication. #49

Jsyro opened this issue Jun 14, 2023 · 3 comments

Comments

@Jsyro
Copy link
Contributor

Jsyro commented Jun 14, 2023

What

Using the did:peer:2 example found on the identity foundation page here. I was unable to use the library on it for two reasons.

  1. The did ends with the .S entry, which is base64 encoded, and base64 uses = as padding, however the REGEX found in the pydid library here does not accept the = and throws an error. Maybe this library can strip those =, or I can submit an issue to that repo as well.

  2. The .E entry after decode_multibase_numbasis has the relationship AUTHENTICATION, however the _build_did_doc_numalgo_2() only accepts the relationship KEY_AGREEMENT. found on this line.

Why

Is there an issue with example? or is there a different method I should need to use? I am just learning about did:peer messages and documents, but my goal is to change the aries-cloudagent-python project to use did:peer:2 and possibly did:peer:3.

Success Criteria

  • Base64 padding should be handled, either by pydid or this library - see here
  • did doc should be created from this did successfully.

Anything Else

If .E entry must by of type KEY_AGREEMENT and the .V must have relationship of type AUTHENTICATION, is there an issue with the example I am using? Or is there error handling that can nudge the developer in the right direction?

@andrewwhitehead
Copy link
Contributor

IMO base64 padding should never be used. Making it optional means that two or more DIDs (padded/unpadded) would have the same basis, and it should be possible to compare them as strings without normalizing. Also, under the method 2 section the spec does specify for the service entry: "Base64URL Encode String (no padding)" so I think the example needs updating.

Also looking at that example, the encryption key entry decodes to 0xED ... which indicates an Ed25519 signing key. That doesn't make sense, it should be 0xEC for an X25519 key.

@Jsyro
Copy link
Contributor Author

Jsyro commented Jun 15, 2023

Using the examples in this libraries tests and comparing, it becomes clear how to use this library. Unsure how to reconcile that the example documentation for the protocol is incompatible.

@Jsyro
Copy link
Contributor Author

Jsyro commented Jun 22, 2023

Spec and examples have been updated to clarify that padding characters = are not valid in dids, any base64 encoding of entrys to be used in a DID must trim these.

decentralized-identity/peer-did-method-spec#52 (comment)

pydid library will not be changed. Indicio-tech/pydid#62

Update:
The first reason has been resolved as an error in the spec and examples
The second reason for failure on the example may or may not be legitimate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants