What we need to work out here are commonalities and where do we need to adjust according to the spec of JFF. Meaning that we find a shared JSON structure inside the attachement or where do we put the layer

We find commonalities of of we will do issuance.
Its probably only what is inside the attachment that matters I assume.

The service property of did:peer doesn't align with what is required from didcomm v2.. If we go the did:peer approach we will either have to misalign with didcomm or did:peer

What we need to work out here are commonalities and where do we need to adjust according to the spec of JFF. Meaning that we find a shared JSON structure inside the attachement or where do we put the layer

We also have to understand what does the attachement here offer of functionality

Here we are using the service endpoint discovery method. This can change because of the did:peer things.
We also use goal and accept to adress what is what

{
  "id": "62c5666fbfecac42e632d703",
  "to": [
    "did:key:z6MkeXQbsmxZYtpZ5PKgib56E5rqvFRHNqg5YoQ11zrwsksJ"
  ],
  "typ": "application/didcomm-plain+json",
  "from": "did:key:z6MkkgfrEB9gSvpJui6yLmqHhcuuLjto9QXKCSa4WtHai4KR",
  "thid": "f62e3124-3113-4147-8203-b7f899699ef3",
  "attachments": [],
  "type": "https://didcomm.org/out-of-band/2.0/invitation",
  "body": {
    "goal": "Issue VC",
    "goal_code": "issue_vc",
    "accept": [
      "didcomm/v2"
    ],
    "service": {
      "id": "did:key:z6MkkgfrEB9gSvpJui6yLmqHhcuuLjto9QXKCSa4WtHai4KR#did-communication",
      "type": "DIDCommMessaging",
      "serviceEndpoint": "https://dev-open-messages-api-lth4gowdyq-ew.a.run.app/messages",
      "priority": 0
    }
  }
}

We also use an accept message to accept the invitation, but that can be ignored

OOB accept
{
  "id": "62c56c090fba490019b4de9d",
  "to": [
    "did:key:z6MkkgfrEB9gSvpJui6yLmqHhcuuLjto9QXKCSa4WtHai4KR"
  ],
  "typ": "application/didcomm-plain+json",
  "from": "did:key:z6MkeXQbsmxZYtpZ5PKgib56E5rqvFRHNqg5YoQ11zrwsksJ",
  "thid": "f62e3124-3113-4147-8203-b7f899699ef3",
  "attachments": [],
  "type": "https://didcomm.org/out-of-band/2.0/accept",
  "body": {
    "goal": "Issue VC",
    "goal_code": "issue_vc",
    "accept": [
      "didcomm/v2"
    ],
    "service": {
      "id": "did:key:z6MkeXQbsmxZYtpZ5PKgib56E5rqvFRHNqg5YoQ11zrwsksJ#did-communication",
      "type": "DIDCommMessaging",
      "serviceEndpoint": "https://dev-open-messages-api-lth4gowdyq-ew.a.run.app/messages",
      "priority": 0
    }
  }
}

Just to find some commonality on the ACK as well

Proposal:

In the offer-credential message the dif/credential-manifest/[email protected] attachment contains a presentation_definition within the credential_manifest, describing the proof challenge and proof domain for a DID Authentication VP.

The following request-credential message has a dif/credential-manifest/[email protected] attachment that is a VP which includes the previously mentioned challenge and domain in it's proof.

Please make a simple swimlane work like Brian have and add it here, so we can map things out.

Here is Diwala flow.

@brianorwhatever can you add yours here as well? So we have a simple issue to scroll and compare on. Just felt easier than doing a PR

There is now two versions of PE. Should we agree to use v1 or v2?

How can an Issuer issue a credential to a holder that is using a DID method that doesn't contain a service property (ie. did:key)?