Skip to content
This repository has been archived by the owner on Mar 27, 2024. It is now read-only.

fix: fixes for didexchange interop with aca-py #2655

Merged
merged 1 commit into from
Mar 23, 2021

Conversation

Moopli
Copy link
Contributor

@Moopli Moopli commented Mar 19, 2021

accept old and new didexchange message formats and mime types:

  • application/ssi-agent-wire is accepted as an inbound mime type
  • did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0 is accepted as
    an inbound PIURI for didexchange messages
  • did doc can be parsed from "did_doc~attach" attachment in request
    messages, as per didexchange spec, in addition to being accepted
    inside "connection" field, as per connection-request spec

did doc format:

  • Parse legacy peer did docs with publicKey members even if their
    context states they are using a newer format.
  • Translate raw ed25519 public key values to did:key when reading
    recipient keys or routing keys

Signed-off-by: Filip Burlacu [email protected]

@codecov
Copy link

codecov bot commented Mar 19, 2021

Codecov Report

Merging #2655 (9b5a622) into main (a0e436a) will increase coverage by 0.03%.
The diff coverage is 97.01%.

❗ Current head 9b5a622 differs from pull request most recent head 6c829dd. Consider uploading reports for the commit 6c829dd to get more accurate results
Impacted file tree graph

@@            Coverage Diff             @@
##             main    #2655      +/-   ##
==========================================
+ Coverage   88.38%   88.41%   +0.03%     
==========================================
  Files         265      265              
  Lines       20695    20757      +62     
==========================================
+ Hits        18291    18353      +62     
  Misses       1404     1404              
  Partials     1000     1000              
Impacted Files Coverage Δ
pkg/didcomm/common/service/did_comm_msg.go 95.34% <0.00%> (-1.51%) ⬇️
pkg/didcomm/common/service/destination.go 100.00% <100.00%> (ø)
pkg/didcomm/protocol/didexchange/service.go 89.13% <100.00%> (+0.61%) ⬆️
pkg/didcomm/protocol/didexchange/states.go 89.41% <100.00%> (+0.07%) ⬆️
pkg/didcomm/transport/http/inbound.go 81.53% <100.00%> (ø)
pkg/doc/did/doc.go 88.31% <100.00%> (+0.52%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a0e436a...6c829dd. Read the comment docs.

@Moopli Moopli force-pushed the didex-msg branch 2 times, most recently from d118a44 to 21c497a Compare March 20, 2021 02:59
@Moopli Moopli marked this pull request as ready for review March 20, 2021 03:10
@@ -44,6 +46,17 @@ const (
ResponseMsgType = PIURI + "/response"
// AckMsgType defines the did-exchange ack message type.
AckMsgType = PIURI + "/ack"
// OldPIURI is the old did-exchange protocol identifier URI.
OldPIURI = "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0"
Copy link
Contributor

@troyronda troyronda Mar 20, 2021

Choose a reason for hiding this comment

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

@swcurran @andrewwhitehead when will this old PIURI base (did:sov:BzCbsNYhMrjHiqZDTUASHg;spec) no longer be sent from AcaPy?

Noticed in msg transition:

In step 2 - community is updating implementations to send new formats. Target Completion Date: 2020.10.15"

Copy link
Contributor

@troyronda troyronda Mar 20, 2021

Choose a reason for hiding this comment

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

Also, probably worth noting that DID Exchange was one of the "new" protocols. @swcurran @andrewwhitehead

From msg transition:

Note: Any RFCs that already use the new "https" message type should continue to use the use new format in all cases—accepting and sending. New protocols defined in new and updated RFCs should use the new "https" format.

Copy link

@andrewwhitehead andrewwhitehead Mar 21, 2021

Choose a reason for hiding this comment

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

At the moment ACA-Py has a startup option to use the new URI prefix on outgoing messages. If the .NET framework now accepts that then we may be able to make it the default in the next release. Changing the prefix is automatic, so it doesn't have custom behaviour depending on the message type (ie. did-exchange).

Copy link
Contributor

@troyronda troyronda Mar 21, 2021

Choose a reason for hiding this comment

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

Looks like .NET has https handling code for the HTTPs prefixes. Can you please switch the default @swcurran @andrewwhitehead @tmarkovski - we should be using the https prefix in the test harness (and generally). openwallet-foundation/acapy#1042

Choose a reason for hiding this comment

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

@andrewwhitehead -- ACA-Py should be using the new prefix's on all new protocols anyway -- such as DID Exchange.

We need to do a quick pass through the various mobile agents to ensure that all still work, but I think we are good with switching.

We really need to figure out how to do these community updates better -- how we can communicate when we can go from step to step reliably. Basically -- that means we need participation from those involved -- software creators that build the frameworks and those that deploy them. It's the latter that is the tricky part.

@@ -21,6 +21,11 @@ import (

var logger = log.New("aries-framework/http")

const (
// acceptInboundContentType additional content type to be accepted for inbound messages.
acceptInboundContentType = "application/ssi-agent-wire"
Copy link
Contributor

@troyronda troyronda Mar 20, 2021

Choose a reason for hiding this comment

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

@swcurran @andrewwhitehead when does this old media type (application/ssi-agent-wire) go away?

Choose a reason for hiding this comment

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

Again need to test with the .NET framework, last I checked it only accepts this one.

Copy link
Contributor

@troyronda troyronda Mar 21, 2021

Choose a reason for hiding this comment

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

@@ -50,5 +50,5 @@ func (v *VDR) Deactivate(did string, opts ...vdrapi.DIDMethodOption) error {

// Accept did method.
func (v *VDR) Accept(method string) bool {
return method == DIDMethod
return method == DIDMethod || method == "sov" // accept sov 'peer' did docs for interop
Copy link
Contributor

Choose a reason for hiding this comment

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

@swcurran @andrewwhitehead @Moopli @llorllale I don’t understand this one. Why would a did:sov be interpreted as did:peer?

Choose a reason for hiding this comment

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

If our peer DID docs are using did:sov then that's likely an error, although standardizing on did:peer also doesn't seem ideal until that spec is finalized.

Copy link
Contributor

Choose a reason for hiding this comment

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

@Moopli @andrewwhitehead we can't treat did:sov as did:peer - if we are being sent did:sov, we must resolve it using the did:sov driver.

If this is happening, AcaPy must fix it.

Copy link
Contributor

@troyronda troyronda Mar 21, 2021

Choose a reason for hiding this comment

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

@Moopli please revert this change and describe the problem in an AcaPy issue.

Choose a reason for hiding this comment

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

@andrewwhitehead -- let us know the state of this. If this convention is in the wild, how do we eliminate it without breaking the interop we have today and add the interop we need tomorrow.

Choose a reason for hiding this comment

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

@swcurran I'd start by just generating our current peer DID Doc implementation with the did:peer prefix to see how that works with interop (assuming we don't currently use did:peer, but I can't see any references to it in the code base). Maybe @sklump could have a look at that this week?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@troyronda @andrewwhitehead I raised an issue over on aca-py for this openwallet-foundation/acapy#1048

Copy link
Contributor

Choose a reason for hiding this comment

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

return doc, nil
}

func legacyParseSov(raw *rawDoc) (*Doc, error) {
Copy link
Contributor

@troyronda troyronda Mar 20, 2021

Choose a reason for hiding this comment

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

@swcurran @andrewwhitehead DID v1 documents now use the verificationMethod property not publicKey. I.e., We are receiving an invalid DID document and this is special handling due to that.

Choose a reason for hiding this comment

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

Again need to check with the .NET framework but I don't think it will accept verificationMethod.

Copy link
Contributor

Choose a reason for hiding this comment

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

Choose a reason for hiding this comment

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

It's about a community upgrade. When the first cut was implemented "publicKeys" was the attribute name in the then DID Core spec.

Copy link
Contributor

@troyronda troyronda Mar 22, 2021

Choose a reason for hiding this comment

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

@@ -246,7 +259,11 @@ func (s *Service) Accept(msgType string) bool {
return msgType == InvitationMsgType ||
msgType == RequestMsgType ||
msgType == ResponseMsgType ||
msgType == AckMsgType
msgType == AckMsgType ||
msgType == OldInvitationMsgType ||
Copy link
Contributor

@troyronda troyronda Mar 20, 2021

Choose a reason for hiding this comment

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

I'd prefer doing a string replace of did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/ => https://didcomm.org/ at a higher layer. I assume this isn't the only case of this old PIURI being sent from AcaPy?

@Moopli @llorllale

Copy link
Contributor

Choose a reason for hiding this comment

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

@@ -23,6 +26,8 @@ type Destination struct {

const (
didCommServiceType = "did-communication"
// legacyDIDCommServiceType is the non-spec service type used by legacy didcomm agent systems.
legacyDIDCommServiceType = "IndyAgent"
Copy link
Contributor

@troyronda troyronda Mar 21, 2021

Choose a reason for hiding this comment

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

@@ -603,7 +650,7 @@ func getVerification(doc *Doc, rawVerification interface{},
return nil, errors.New("rawVerification is not map[string]interface{}")
}

if context == contextV011 {
if legacy || context == contextV011 {
Copy link
Contributor

@troyronda troyronda Mar 22, 2021

Choose a reason for hiding this comment

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

this is a bit unfortunate @fqutishat @Moopli
i.e., detecting legacy at two different layers.

err = validate(data, raw.schemaLoader())

switch {
case strings.HasPrefix(raw.ID, "did:sov:"):
Copy link
Contributor

Choose a reason for hiding this comment

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

This might not be 100% correct. This is more a case of AcaPy currently sending some document in DID exchange as did:sov ...
@fqutishat @Moopli

Copy link
Contributor

Choose a reason for hiding this comment

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

yes

Copy link
Contributor

@troyronda troyronda Mar 22, 2021

Choose a reason for hiding this comment

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

@Moopli It would be safer to detect this case in DID Exchange code rather than here.

@Moopli Moopli force-pushed the didex-msg branch 2 times, most recently from 7b3cad0 to d6d7736 Compare March 23, 2021 08:19
@@ -25,6 +25,9 @@ const (
jsonThreadID = "thid"
jsonParentThreadID = "pthid"
jsonMetadata = "_internal_metadata"

oldPIURI = "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/"
newPIURI = "https://didcomm.org/"
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's not call this one "new".

@@ -74,6 +74,11 @@ type Request struct {
Label string `json:"label,omitempty"`
Connection *Connection `json:"connection,omitempty"`
Thread *decorator.Thread `json:"~thread,omitempty"`
// DID the did of the requester. Optional, may be present within `connection` instead.
Copy link
Contributor

@troyronda troyronda Mar 23, 2021

Choose a reason for hiding this comment

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

@llorllale @Moopli - is the DID property supposed to be optional or is this for interop?

I see DocAttach is optional in the RFC.

Copy link
Contributor

Choose a reason for hiding this comment

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

// Interop: handle legacy did docs that incorrectly indicate they use the new format
if requiresLegacyHandling(raw) {
ctx, _ := json.Marshal(raw.Context)
println("legacy:", string(ctx))
Copy link
Contributor

Choose a reason for hiding this comment

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

@Moopli please remove prints.


p, err := peer.New(ctx.StorageProvider())
if err != nil {
return fmt.Errorf("create new vdr peer failed: %w", err)
}

// Interop: use a did:sov VDR that will prefer to store sov DID docs locally, by wrapping the did:peer VDR.
Copy link
Contributor

Choose a reason for hiding this comment

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

@Moopli - no, you cannot override did:sov at this level. Needs to be within did exchange only.

Copy link
Contributor

@troyronda troyronda Mar 23, 2021

Choose a reason for hiding this comment

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

Let's remove this change and topic from this PR. @Moopli

SPDX-License-Identifier: Apache-2.0
*/

package sov
Copy link
Contributor

Choose a reason for hiding this comment

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

@Moopli - no - this is not did:sov. It is confusing to have this package named sov in vdr.

Additionally, it doesn't really help. You need to fix the document in did exchange.

Copy link
Contributor

@troyronda troyronda Mar 23, 2021

Choose a reason for hiding this comment

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

Let's remove this change and topic from this PR @Moopli

@Moopli Moopli force-pushed the didex-msg branch 2 times, most recently from 5ffe344 to 82ab026 Compare March 23, 2021 14:28
@Moopli Moopli force-pushed the didex-msg branch 2 times, most recently from c80f86b to 0565bea Compare March 23, 2021 14:34
@@ -404,6 +410,22 @@ func ParseDocument(data []byte) (*Doc, error) {
return doc, nil
}

func requiresLegacyHandling(raw *rawDoc) bool {
if len(raw.PublicKey) == 0 { // docs in v1 format don't have a top-level publicKey array
Copy link
Contributor

Choose a reason for hiding this comment

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

|| len(raw.VerificationMethod) > 0

Copy link
Contributor Author

Choose a reason for hiding this comment

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

|| or &&? if we get a doc that has no keys, should we do legacy tweaks?

accept old and new didex. message formats and mime types:
- application/ssi-agent-wire is accepted as an inbound mime type
- did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0 is accepted as
  an inbound PIURI for didexchange messages
- did doc can be parsed from "did_doc~attach" attachment in request
  messages, as per didexchange spec, in addition to being accepted
  inside "connection" field, as per connection-protocol spec

did doc format:
- Parse legacy peer did docs with publicKey members even if their
  context states they are using a newer format.
- Translate raw ed25519 public key values to did:key when reading
  recipient keys or routing keys

Signed-off-by: Filip Burlacu <[email protected]>
Label string `json:"label,omitempty"`
Thread *decorator.Thread `json:"~thread,omitempty"`
// DID the did of the requester.
// Mandatory in did-exchange, but optional for backwards-compatibility with rfc 0160 connection protocol.
Copy link
Contributor

Choose a reason for hiding this comment

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

@Moopli @llorllale do we have more description of why backwards-compatibility with RFC 0160 is needed?

Copy link
Contributor

Choose a reason for hiding this comment

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

RFC0160 is not in the AIP 2.0 draft so far: https://github.com/hyperledger/aries-rfcs/pull/579/files?short_path=a9296f0#diff-a9296f04f44f2daa050b1b0724458240a85f029aa7b77ed83b17a5479ef97f85

We should probably confirm, but I believe there is a desire to deprecate RFC0160 going forward.

cc @swcurran @andrewwhitehead

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@troyronda I have to look through aca-py to see if any elements of 0160 are still used there - this, in particular, is a place where afgo was behind.

@Moopli Moopli requested a review from troyronda March 23, 2021 15:22
@troyronda troyronda merged commit d769e21 into hyperledger-archives:main Mar 23, 2021
sudeshrshetty pushed a commit to sudeshrshetty/aries-framework-go that referenced this pull request Oct 18, 2021
…2655)

accept old and new didex. message formats and mime types:
- application/ssi-agent-wire is accepted as an inbound mime type
- did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0 is accepted as
  an inbound PIURI for didexchange messages
- did doc can be parsed from "did_doc~attach" attachment in request
  messages, as per didexchange spec, in addition to being accepted
  inside "connection" field, as per connection-protocol spec

did doc format:
- Parse legacy peer did docs with publicKey members even if their
  context states they are using a newer format.
- Translate raw ed25519 public key values to did:key when reading
  recipient keys or routing keys

Signed-off-by: Filip Burlacu <[email protected]>
sudeshrshetty pushed a commit to sudeshrshetty/aries-framework-go that referenced this pull request Jan 22, 2022
…2655)

accept old and new didex. message formats and mime types:
- application/ssi-agent-wire is accepted as an inbound mime type
- did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0 is accepted as
  an inbound PIURI for didexchange messages
- did doc can be parsed from "did_doc~attach" attachment in request
  messages, as per didexchange spec, in addition to being accepted
  inside "connection" field, as per connection-protocol spec

did doc format:
- Parse legacy peer did docs with publicKey members even if their
  context states they are using a newer format.
- Translate raw ed25519 public key values to did:key when reading
  recipient keys or routing keys

Signed-off-by: Filip Burlacu <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

6 participants