You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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?
The text was updated successfully, but these errors were encountered:
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.
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.
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.
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.
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.
The did ends with the.S
entry, which is base64 encoded, and base64 uses=
as padding, however the REGEX found in thepydid
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.The
.E
entry afterdecode_multibase_numbasis
has the relationshipAUTHENTICATION
, however the_build_did_doc_numalgo_2()
only accepts the relationshipKEY_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- see herepydid
or this libraryAnything Else
If
.E
entry must by of typeKEY_AGREEMENT
and the.V
must have relationship of typeAUTHENTICATION
, is there an issue with the example I am using? Or is there error handling that can nudge the developer in the right direction?The text was updated successfully, but these errors were encountered: