RFCs 023 and 0094 contradiction around routing

[jovfer]

There are 3 options of invitation message https://github.com/hyperledger/aries-rfcs/tree/master/features/0023-did-exchange#0-invitation-to-exchange One of them is the case of Invitation Message with Keys and URL endpoint

{
    "@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0/invitation",
    "@id": "12345678900987654321",
    "label": "Alice",
    "recipientKeys": ["8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K"],
    "serviceEndpoint": "https://example.com/endpoint",
    "routingKeys": ["8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K"]
}

According to https://github.com/hyperledger/aries-rfcs/tree/master/features/0023-did-exchange#request-transmission the connection request for this invitation should be wrapped by fordard message via 8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K key. And there is no way in Forward message definition to do it https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0094-cross-domain-messaging#corerouting10forward as there is no way to define to filed as we have only key itself, but to may be either

• A DID without a key reference (e.g. did:sov:1234abcd)
• A DID with a key reference (e.g. did:sov:1234abcd#4)

it seems like a contradiction between RFCs

[lovesh]

Should we change RFC 94 to allow a key as well in the to field of Forward message?

[tmarkovski]

Currently, we are using the "to" field to populate it with key, between aca-py and aries .net.

Should we change RFC 94 to allow a key as well in the to field of Forward message?

I would add a new field to indicate it's a key, rather then a DID Doc reference. Otherwise, we'd have to complex parsing on the value of the field to determine what it designates.

Additionally, I think we should use the ~service decorator reference in the invitation message, rather than flattened copy of the decorator.

[kdenhartog]

Would this need to be an actual key, a reference to a key, or a JWK? I suspect like elsewhere it would need to be a JWK. @dhh1128 looks like this is becoming a common problem that we may want to standardize around the use of JWKs.

[TelegramSam]

Current practice is to use a key in the to attribute. We should update the routing RFC to reflect this, and leave further discussion to another issue.

[TimoGlastra]

It seems all implementations use a key in the to attribute, but RFC 0094 still uses a did or key reference. Should we update RFC 0094 to update this to a key? For AIP we decided to lean towards using did:key (https://github.com/hyperledger/aries-rfcs/blob/main/features/0360-use-did-key/README.md) in most places, is RFC0094 been forgotten to be updated?

[swcurran]

I think a clarification would be useful. RFC 0094 is a concept vs. a feature, so it is more about the ideas conveyed than the precise details, but accuracy always helps. I suggest that the example(s) be updated to what is commonly implemented, and some text follow that provides a bit more context about the options/usage.

That said, I think an implementer is best positioned to put in this update vs. me making the change.