NON ARIES - What does your OOB invitation contain?

[vongohren]

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
    }
  }
}

[brianorwhatever]

{
  "type": "https://didcomm.org/out-of-band/2.0/invitation",
  "id": "00b000545551b5368f086f8d7361a7f43b999bca52ade6bca5c8ca9381f230b8",
  "from": "did:web:aviary.id",
  "body": {
    "goal_code": "streamlined-vc",
    "accept": ["didcomm/v2"]
  }
}

[brianorwhatever]

@vongohren the length of your OOB invitation runs the risk of not reading well as a QR code as there is a lot of data. This is the number 1 reason not to have the service in there. We should also drop empty fields (attachments). I'm also wondering how the issuer would get the did for the to field as this is the first interaction. Here is yours vs mine

[AlexAndrei98]

@vongohren the length of your OOB invitation runs the risk of not reading well as a QR code as there is a lot of data. This i

Hey Brian, something that was implemented by the didcomm community to deal with this problem is https://didcomm.org/shorten-url/1.0/. At root's id we implemented it at the mediator level here is an exmaple: https://github.com/roots-id/didcomm-mediator

[vongohren]

@vongohren the length of your OOB invitation runs the risk of not reading well as a QR code as there is a lot of data. This is the number 1 reason not to have the service in there. We should also drop empty fields (attachments). I'm also wondering how the issuer would get the did for the to field as this is the first interaction. Here is yours vs mine

Valid questions @brianorwhatever, I agree with empty fields and service coming from a different place, such as a did. We have just no had the issue of QR codes yet.

And since it has been allowed to provide a JSON message behind a hosted URL, meaning I can basically put

https://dev-open-messages-api-lth4gowdyq-ew.a.run.app/path?_oobid=66095855-8b1f-4fbd-bf74-7f3621a7fd57

Which will load the JSON message of OOB. As per spec: https://identity.foundation/didcomm-messaging/spec/#short-url-message-retrieval

What is your thoughts on this?

We should try to offer up different type of messages, as long as here is some data there that allows for understanding how to connect. Like we dont have to have all fields the same, many can be ignorable by a side. As long as the most important are there.

Ref the to field

Yes that is a waste from us. We have been in a funk trying to figure out if we could restrict the invitation to a did we already knew. But that is also silly, why the need for an invitation when we know of the did :P Let me double check what was the reasoning.

[brianorwhatever]

yeah that is great point you two have made, we might want to accept json invations and url-shortened invitations. If we do both I would like to use the didcomm protocol alex posted above but this does increase the implementation scope

[vongohren]

But do we need to use a protocol for something that is very clearly specified in the spec as an opportunity for OOB? Im just wary that it says in the spec about short urls. And for privacy concerns I dont see the issue, since you are replying to the message anyway, so you want to communicate to that endpoint

[brianorwhatever]

hmm that's very true I didn't really think about it but I as the issuer would be completing the protocol with myself which doesn't make sense. In this case I don't think the protocol makes sense to use here. I suppose the use case for the protocol would be to have an invitation with a mediator. This might make sense if a wallet that doesn't have a persistent DID somewhere wanted to create an invitation.

[AlexAndrei98]

{
  "type": "https://didcomm.org/out-of-band/2.0/invitation",
  "id": "e5fb2cc4-fbbd-4d7f-a3d3-8a93758fa6f7",
  "from": "did:peer:2.Ez6LSc7Abj5qZiNAqrmzNRnzxQEkZZbfNUPPNmwrCw4Gh3zw5.Vz6MknAzBHpSHXsBycQd3mNGphjWiZPt6tJbkDrkLYqzh5d5M.SeyJpZCI6Im5ldy1pZCIsInQiOiJkbSIsInMiOiJodHRwOi8vMTI3LjAuMC4xOjgwMDAiLCJhIjpbImRpZGNvbW0vdjIiXX0",
  "body": {
    "goal_code": "streamlined-vc",
    "accept": ["didcomm/v2"]
  }
}

[vongohren]

We will work with the message both RootsID and AviaryTech has implemented, and move onwards from there. What the other group will align on, is a bit up to them

[brianorwhatever]

here is what I have implemented: differs only in that it adds the created_time

{
    "id": "29fedb24f146cd7493e3609aadb6ca5b2d627d5f48423b0dfc6d925297922377",
    "type": "https://didcomm.org/out-of-band/2.0/invitation",
    "created_time": 1670006881,
    "from": "did:web:verifiable.ink",
    "body": {
        "accept": [
            "didcomm/v2"
        ],
        "goal_code": "streamlined-vc"
    }
}