Out of band - proposing change ( `services` VS `from` )

Hi, please take this with a grain of salt, I am looking just to hear some of your thoughts to see what's the community thinking. Not looking to break applications and give implementors new headaches.

Currently the way out of band RFC is defined, it's possible the objects under services attribute can be either:

DID
or service object, which looks as service object in https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html

Example from the oob spec:

{
  "@type": "https://didcomm.org/out-of-band/%VER/invitation",
  "@id": "<id used for context as pthid>",
  "label": "Faber College",
  "handshake_protocols": ["https://didcomm.org/didexchange/1.0"],
  "services": [
    {
      "id": "#inline",
      "type": "did-communication",
      "recipientKeys": ["did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH"],
      "routingKeys": [],
      "serviceEndpoint": "https://example.com:5000"
    }
  ]
}

Back in the days when did:peer was not yet widely adopted, I can see how this was useful.

However nowadays, did:peer seem to be superior & cleaner approach to achieve the same: Instead of building up and embedding service object as on example, I can include the service information as part of did:peer.

{
  "@type": "https://didcomm.org/out-of-band/%VER/invitation",
  "@id": "<id used for context as pthid>",
  "label": "Faber College",
  "handshake_protocols": ["https://didcomm.org/didexchange/1.0"],
  "services": ["did:peer:2.Vz41yQz4vq7DcU1.SeyJ0IjoiZG0iLCJzIjoiaHR0cDovL2V4YW1wbGUub3JnLyIsImEiOlsiZGlkY29tbS9haXAyO2Vudj1yZmMxOSJdfQ"]
}

In didcomm v2, apparently a lesson was taken from here, as there's only from field which IS a single DID

I am wondering if while didcomm v1 is still used a lot out there in wild, whether it the community would find it reasonable to make ammendments to Aries OOB protocol to address the issue. I don't mind how that would be done, but I'd like to see if we can do something. (I can imagine a major bump with breaking change, or minor version ammendment simply adding new "from" field which shall be preferred in favor of "services"). One way to think about this is taking baby step towards didcomm v2 in a way becoming more similar. Major benefit I see in simplifying implementations. We tried to support both forms (did, embedded) in aries_vcx implementation and obviously things would be simpler if we have guarantee that we just need to "think in DID terms".

hyperledger / aries-rfcs

Out of band - proposing change ( `services` VS `from` ) #802