Service encoding according to DIDComm v2

[dbluhm]

Linked below is the current service encoding done by this library:
https://github.com/sicpa-dlab/peer-did-python/blob/main/peerdid/core/peer_did_helper.py#L42-L139

Notice that the encoding does not recursively descend into the service object.

Linked here is the spec for service endpoints for DIDComm v2 messaging:
https://identity.foundation/didcomm-messaging/spec/v2.0/#service-endpoint

Notice that the structure has changed from:

{
    "id": "did:example:123456789abcdefghi#didcomm-1",
    "type": "DIDCommMessaging",
    "serviceEndpoint": "https://example.com/path",
    "accept": [
        "didcomm/v2",
        "didcomm/aip2;env=rfc587"
    ],
    "routingKeys": ["did:example:somemediator#somekey"]
}

To:

{
    "id": "did:example:123456789abcdefghi#didcomm-1",
    "type": "DIDCommMessaging",
    "serviceEndpoint": [{
        "uri": "https://example.com/path",
        "accept": [
            "didcomm/v2",
            "didcomm/aip2;env=rfc587"
        ],
        "routingKeys": ["did:example:somemediator#somekey"]
    }]
}

This library should probably support both the "original" service format and the current spec defined service format.

[dbluhm]

cc @mepeltier

[dkulic]

@dbluhm, I am not sure how the encoding should work, because if I have (in "original" format):

[
    {
        "type": "DIDCommMessaging",
        "serviceEndpoint": "https://example.com/endpoint",
        "routingKeys": [
            "did:example:somemediator#somekey"
        ],
        "accept": [
            "didcomm/v2",
            "didcomm/aip2;env=rfc587"
        ]
    },
    {
        "type": "DIDCommMessaging",
        "serviceEndpoint": "https://example.com/endpoint2",
        "routingKeys": [
            "did:example:somemediator#somekey2"
        ]
    }
]

it is encoded like (just without whitespace, which is added for readability):

[
    {
        "t": "dm",
        "s": "https://example.com/endpoint",
        "r": ["did:example:somemediator#somekey"],
        "a": ["didcomm/v2","didcomm/aip2;env=rfc587"]
    },
    {
        "t": "dm",
        "s": "https://example.com/endpoint2",
        "r": ["did:example:somemediator#somekey2"]
    }
]

But with newer format we have something like:

{
    "type": "DIDCommMessaging",
    "serviceEndpoint": [
        {
            "uri": "https://example.com/endpoint",
            "routingKeys": [
                "did:example:somemediator#somekey"
            ],
            "accept": [
                "didcomm/v2",
                "didcomm/aip2;env=rfc587"
            ]
        },
        {
            "uri": "https://example.com/endpoint2",
            "routingKeys": [
                "did:example:somemediator#somekey2"
            ]
        }
    ]
}

How this should be encoded in did:peer ?

[dbluhm]

The same term shortening should take place in the nested structures:

{
    "t": "DIDCommMessaging",
    "s": [
        {
            "uri": "https://example.com/endpoint",
            "r": [
                "did:example:somemediator#somekey"
            ],
            "a": [
                "didcomm/v2",
                "didcomm/aip2;env=rfc587"
            ]
        },
        {
            "uri": "https://example.com/endpoint2",
            "r": [
                "did:example:somemediator#somekey2"
            ]
        }
    ]
}

uri isn't included in the list of terms to shorten (yet, I suppose) so it will be unaffected.