message based interaction / DIDComm

[fimbault]

Since we now have worked a solution for standard interactions #164 (which is nice when end-user = RO), we could now review if more advanced scenarii make sense.
There's another case which is not complex, you don't even need an interaction (then end-user != RO but RO is a rule engine from an organisation).

But I see at least 2 more advanced cases:

• message interactions. Would be most useful when end-user != RO (and we suppose the RO is also a natural person here).
• multi-step interactions Multi-step interaction methods #89. Messaging patterns could enable sequential or parallel flow of communications, therefore enabling multi-step if you can have a proper way to declare the interaction completed (although how that would work is not clear).

-> Use case 1 : on first use, a message (signed by the AS) is sent from the client, on behalf of the end-user (for instance a doctor) to a recipient (the RO, for instance a patient). The patient could choose to allow a one-time access or more durable access (probably limited to a maximum time), in which case we fallback on the no interaction case seen above for similar follow-up requests.

-> potential start methods : DIDComm, DIDComm query, RCS messaging, email, etc. (probably need to limit to secure channels though...). Note that DIDComm was already discussed as a possibility in oauth.xyz (interaction section).

The details of how that communication would work is not straightforward.

• Probably the end-user and the AS would have to know the RO (e.g. DIDComm to address, telephone number in case of RCS messaging, etc.), how does this happen?
• How do you handle trust on first use? (a problem unresolved for DIDComm, but PAKE or similar could be useful)
• How do you avoid spoofing ROs with unwanted requests?
• Supposing the recipient answers, how do you establish a duplex request-response for the consent request? (probably you'd need a specific DIDComm type).
• The risk of unrecoverable error / panic (example : RO unreachable) is much more likely than in the usual redirect

[agropper]

This relates to a major privacy discussion in the closing days of the DID Core spec w3c/did#324 It's desirable to avoid fingerprinting and traffic analysis by keeping the entropy of a DID and DID Document as high as possible. This means limiting the content of the DID Document to only those elements that involve control. Ideally, a DID would control only one service endpoint. Should that service endpoint be a messaging (inbox) or an authorization server?

In an AS first world, inbox access would look like any other request for authorization.

Note also that there are many reasons for a resource server to want to message the RO. This happens when the RS gets a valid access authorization but an exception occurs such as a jurisdictional issue or a decision that the client is untrusted for some reason. In US healthcare law, for example, the RS MAY ask the client for a signed software statement and if the client certificate does not provide an adequate root of trust then the RS MUST notify the RO (a "black box warning") and allow the RO to override the client trust issue. This, in effect, looks like a messaging channel between the RS and the RO that can be mediated by the AS.

[fimbault]

-> Target for an extension (+need to check how to best define extension points)

[agropper]

See also #221

[fimbault]

The general principle is layed out in section 4, but without any specific details.
DIDComm itself could be an extension, but there's been no request for it, so closing.