FCP HIPE: Message Types

[dbluhm]

Rendered text

[swcurran]

To confirm - this format would be the literal value used for the value of the "type" field in a the Core Message Structure (per that HIPE) - is that correct? Might be worth combining the two HIPEs as they are pretty intertwined. Or not :-)

I'm fine with the format and don't have strong opinions on the drawback questions about the context/subproject usage.

[dbluhm]

@swcurran Thanks for your comments! They are definitely closely intertwined lol. Initially at least, it felt different enough to propose the two separately. Thinking again now I still think there is some value in being able to standardize a discrete piece of the standard, especially where other topics are more controversial.
Thoughts from others?

[dhh1128]

I'm not sure we want to build a URN hierarchy that puts and in such a root position. If Indy or Sovrin manages to get buyin from some other project or org to use their approach, will this other project want to brand itself under the Indy/Sovrin banner? I am wondering if instead we should begin with message_type:message_family, and if we want to distinguish something that's specific to a particular audience, we just include that in the name of the message family.

[mhailstone]

@dhh1128 From your comment, I think this should at least be brought up in the SSI protocol discussions and be defined and discussed there as well. The hope was that we use the URN approach as is discussed in https://tools.ietf.org/html/rfc8141. We (Indy/Sovrin) would define our own message types, but whichever SSI system is used, the process could know how to identify and resolve the URN to the system and designate/route how to parse the message.

[mhailstone]

Recommended URN expression according to https://tools.ietf.org/html/rfc8141:

urn:<NID>:<NSS>

The NID (Namespace Identifier) portion is the SSI (Self-Sovreign Identity) protocol.

unr:ssi:<NSS>

The NSS (Namespace Specific String) portion would be:

<ssi_system>:<ssi_system_specific_namespace>

For Indy/Sovrin, the ssi_system_specific_namespace would be:

<indy_implementation_platform>:agent:message_type:<domain_organization_controlling_message_type>/<message_family>/<major_family_version>.<minor_family_version>/<message_type>

An example URN for Indy/Sovrin then might be:

urn:ssi:indy:sov:agent:message_type:sovrin.org/connection/1.0/offer

[kdenhartog]

I'm a bit hesitant at the length of the urn proposed at the bottom of your comment @mhailstone but I do like the direction this is headed better than what has been proposed at DIF. For reference, they've been suggesting that we do typing in a MIME style (bottom of the page). here

[TelegramSam]

I propose that the NID is 'ssi', and the NSS is 'message' since we are establishing these to seek common ground between different types. the role of namespace within messages is really the domain portion of the following string. (More comments on that elsewhere)

So, url:ssi:message:example.com/family/1.0/type would be an example. This is both concise and fits the URN design requirements.

[mhailstone]

Message families provide a logical grouping for message types. These families, along with each type belonging to that family, are to be defined in future HIPEs or through means appropriate to the specific indy implementation/platform.

[TelegramSam]

I think it's valuable to talk about the purposes/uses for the type string.

The type string will be used to direct processing of a message within an agent. Every message in a particular family, for example, may be passed to a code package designed to handle that family of messages. The primary automated consumer of the type string is an agent. The primary human consumer of the type string is an agent developer. An agent developer who encounters an unknown type of message will try and figure out the message's purpose and locate documentation.

Types indicate quite a bit about the contents of the message and should be considered as a high correlation risk. It is recommended that type strings be enclosed in the encrypted portion of a message.

The domain portion 'example.com' is used as the namespace of the message family. Common namespaces will likely be sovrin.org and identity.foundation.

It is important that the domain portion allow for custom message types for any developer. This allows for experimentation and development of message families. Some message families will be promoted for broad adoption. Other families may be designed for localized use, which could include use within an organization (like a university) or niche group (like underwater basketweaving enthusiasts)

The domain portion can be any value which easily disambiguates similarly named message families. Using domains carries the drawback of relying upon a non-chain system. DIDs have been proposed as a replacement for using a domain, which itself carries two drawbacks: DIDs are neither human recognizable and are typically long.

It is possible for us to support both formats, or even a new future one, within the same type string specification.

[dbluhm]

I'll revise this HIPE to reflect our discussion at the Agent 2 Agent Workshop.

[TelegramSam]

Looking awesome with the updates. I think we should remove the "Service Selection by Type" section, and just designate that an ID must be used. Since this can be any id (not just spec), I think it's flexible enough without supporting type selection. This will make it easier to parse when necessary.

[swcurran]

Sorry to be a pain, but I'm not a fan having detailed technical information repeated in multiple places. At least the ABNF for a DID that is in this document and appears to be copied from the DID Spec should be removed in favour of a reference/link. Not sure if there are other things in the doc that are the same.

If the information clarifies this document, put a version here - for example, the DID Doc specific to this use of a DID Doc. But information that may become out of sync with it's source should be referenced and not copied.

I'm tempted, but not entirely convinced, to combine this PR with the Agent Messages HIPE. What do other people think?

[dbluhm]

@swcurran not at all, thanks for your comments. As far as I know, the information supplied here is not yet in the DID spec. I'll try to confirm that. If we can pull it out and just link to it, that's fine with me.

As far as combining this with the agent messages HIPE, I'd rather keep things in smaller bite-size pieces for now. It makes it easier to agree on the content contained in the HIPE and officially move it to approved status. If we feel strongly later on that we want this HIPE and the Agent Message HIPE to be combined then I don't see a problem with that.

[nage]

We want to account for at least two kinds of resolution for message types.

1. some DID owns the message type and you resolve the did document, service and under that is the message identifier that can return some data
2. be able to publish the message type spec or schema to the ledger directly to indicate that it is usable by everyone (the ledger would ensure the identifier was unique, probably by just using the ledger sequence number or similar).

We don't need to support method 2 right now, but I think it is important that the addressing scheme is capable of it, because as schemas get more capable I expect there will be more and more overlap between schemas for credentials and schemas for messages and message families.

[dbluhm]

@swcurran Here is the github issue tracking the DID Spec changes we (perhaps prematurely) included in this HIPE: w3c-ccg/did-spec#85

And the PR that I believe will add this: w3c-ccg/did-spec#95

[swcurran]

I think that you should just reference the DID-Spec, not those specific PRs. By definition, we'll use what is in the DID-Spec. Assuming the precise feature we need catches up, we'll use it, but otherwise, we'll still use the mechanism.

If I'm reading this right, the feature for assembling the concrete URL for the DID URI fragment and service endpoint is not yet in the DID-Spec. @nage - I think this should be a reminder for those working on the DID-Spec to push that PR forward.

[dbluhm]

My point was that it isn't in the DID spec yet. I'd love to just provide a link to the DID spec and provide the same information but as it isn't there yet, I felt it pertinent to leave in for now -- if only for our reference. As soon as the PR to the DID spec is merged, let's remove any repeated information and provide that link to the DID spec.