Mapping of KERI service endpoints to services

[pfeairheller]

Currently we only have a mapping from a KERI service endpoint for an AID in the role of Witness and that is mapped to a service with type 'keri-mailbox'. That needs to be updated and others added.

In addition, we need to add other roles to KERI to support external service types like DIDCommMessaging. We should also define service types for all endpoint roles in KERI and submit a PR to add them to:

https://www.w3.org/TR/did-spec-registries/#service-types

[rodolfomiranda]

for DIDCommv2 the service is defined as following:

{
    "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"]
    }
}

or

{
    "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"]
    }]
}

[peacekeeper]

I think KERI supporting arbitrary DID document service types would be a major achievement. There is definitely a sense in certain communities that KERI is "only" about keys and that it can't be used like "real" DIDs.

[rodolfomiranda]

I like the idea of define in the spec a deterministic way to map any DID property into the data field of the key event. We need to consider some kind of operations to add, delete or modify those properties in interaction events

[rodolfomiranda]

Based on todays keri-dev call, Sam's suggestion is to use a specific db to store DIDComm specific information that can be query with rply messages in a predefined route supported by the BADA run mechanism.