DID Communication Callbacks, Hubs, and Agents

DID Communication, Callbacks, Hubs & Agents

Tuesday 1A

Convener: Sam Curren

Notes-taker(s): Colin Jaccino & Sam Curren

Tags for the session - technology discussed/ideas considered:

DID Communication. JWE

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

1. Notes from Colin Jaccino

Starting with assumptions:

• We have a DID, and a DID Document

DID Document contains:

• Endpoint Information
• Keys

Obvious Pattern:

• User with smart phone
• User communicating through a browser
• Server serves up a web site

QR code scanned by a phone presents a URL that the phone uses to get back to the service.  Callback URL.

There is a huge opportunity to standardize how we communicate this callback URL.  

You might have a phone-to-phone use case.  But supporting this case is hard.

There might be a need to be transport agnostic

DID Communicating - if you’re using a DID and it’s a key element that you bring to the use case, the other systems and elements will need to be able to communicate with one another as well to serve your use case.

Audience Comment: you might need to support IOT in addition to servers and application.

Audience: How is this different than just providing the DID in a JWT token that can be passed around?

Convener: That sounds like we will , but the devil is in the details

Audience: You need transport agnosticism, integrity, routing,  Interoperability.

Audience: Interoperability is the hard part.  Standardizing the QR code is important.

Audience: Food for thought requirement - need to support multi-party interactions.  If there are many parties, how can they interact together?  Two party solutions are not enough.

Audience:  Need to break up multi-party into whether its verifiable.  Private?  Is the communication insular?  Group knows who is in the group vs not

Audience: Repudiability? Is everything “on the record”?

Audience: Namespace governance?  Conventions that govern identification of elements.  DID Doc Conventions?

Convener:  We have many communities in the space.  

Hyperledger Indy - Modified form of JWE (JSON Web Encryption) to pass messages that are authenticated encryption.  

Civic

uPort

DifHub

Transmute

Jolocom

Kilt

LifeID

Ways we communicate DIDs relative to Transport Agnosticism

JWT - Reliant on transport security

JWE - moved some of the identifying portion into the protected block.

INDY is JWE

uPort, Civic, Jolocom, Kilt: Uses JWT solution

DifHub - JWS inside of JWE

Since JWT relies on transport encryption, it’s not perfect as transport agnostic

Convener: Would projects that have chosen JWT who then choose to go transport agnostic naturally move toward a solution line JWE?

Audience:  Perhaps a project could use a standard signature in HTTP header.

(Diddery)

Audience: Important to be clear to separate signing and encryption.

Convener: When you have JWT and encryption, we enable non-repudiability.  It’s important that we preserve it.  Are there other paths forward?

• Direct support for DID in TLS?  Standard supports it, but implementations do not.
  • The assumption that there is a certificate store and traceability up to a root certificate is an implementation assumption, not in the spec.  In TLS, it is permissible to trace back to a DID document, instead.  To support this, implementers would have to re-understand the architecture of their certificate verification architecture.

Audience: In zero trust networking, you’re always encrypting at rest and in transit.  You’re always encrypting for the recipient.  TLS doesn’t matter.

Audience: TLS has limited applicability and partial adoption.  TLS doesn’t work over some transports, such as NFC.  Not a safe assumption for protecting the DID.

Audience: TLS is sometimes deliberately man-in-the-middled.  It’s not guaranteed to encrypt end-to-end.  It is not a trustworthy security control.

Audience: You could compromise DIDs the same way we have with TLS. 

Convener: Let’s move past the JWT vs JWE.  There are significant advantages to moving from JWT to JWE.

Audience: If you’re trying to leverage existing tooling,   We just need enough to protect integrity and non-repudiability.

——

Audience (Tobias): Not all DID communications are going on with a browser.  With just a QR code, we may not provide enough context for the services to support the use case.  There may be cases where we shouldn’t be encrypting or hiding the DID.

Convener/Audience: Would moving to JWE be interesting?  Would ubiquitous tooling lead to more adoption of JWE?

Audience: The problem with adoption is that folks aren’t adopting support of DID period.  You need more reference implementations that can be brought into projects to enable uptake.  You want fewer requirements on the underlying infrastructure.

Convener:  Where are the opportunites for more work? 

• There is value in determining the simplest possible way(structure?) to convey the information that must be protected in a message.
  • JSON LD-like type for messages.  Without as much of the “baggage”
  • Message types tend to come in families that support domains of functionality
  • Routing: Uses the content of these message types to simply ask an agent to route on the message flow’s behalf.  “Agent Routing"
    • Audience: please explain more about routing.  don’t we need address space?
    • Convener: Two problems:
      • How to do the routing “on the way in”
      • Routing based on agents.  A node-to-node .  
    • Audience: This is a “circuit-switching” pattern.

Closing

Next conversations:

• Agent routing discussion.
• API Mindset vs Protocol Mindset
  • Multi-party

******************* ********************** ********************** ****************

2. Notes from Sam Curren:

We covered different aspects of DID based communication.

One aspect is message level packaging. Community members are primarily using JWE-ish message encryption, or relying on JWT for signatures and then transport level encryption. 

We will be having further sessions to address specific topics:

Wire-level wrapping (Kyle Den Hartog)

Message Routing (Sam Curren)

API vs Protocol approaches (Daniel Hardman)

Message Structure (Sam Curren + Daniel Buchner)

******************* ********************** ********************** ****************

3. Notes received from Stephen Curran:

Scope of Discussion

If you are using DIDs, how are your peers communicating?

Components:

• DID, DIDDoc, Keys, Endpoints

Challenges in DID Communications

• Different transports provide different levels of trust
  • Nice to have - transport agnostic with same level of trust
  • For example - encrypt/base64 the message and deliver it using any transport
• Persistent endpoints are needed for mobile, implying that some amount of routing is necessary
  • Likely, you don't want your presistent endpoints to be able to see the messages intended to be processed on your mobile device.
• Routing / Software Defined Networks
• Interoperability
• DIDDoc Conventions - how are configurations expressed in the DIDDoc (e.g. routing)?
• Repudiability
• Integrity
• Possible issue (not clear yet): Multi-party communications. That further splits into:
  • Groups
  • parties in a group

What communities are present in the discussion

• Hyperledger Indy
• uPort
• Civic
• DIF Hubs
• Jolocom
• Kilt
• Transmute
• LifeID

Two Basic Approaches Used Today:

1. JWTs with the transport layer handling encryption (usually HTTPS)
   • uPort (also has an encryption option), Civic, Jolocom, Kilt, DIF Hub (for some transactions)
2. JWE (mostly)
   • Hyperledger Indy, DIF Hub (for some transactions)

Side note: Sam Smith

• DIDery is using a signature in HTTP header
• Keep in mind that Signing and Encryption are different activities

For the JWT/Transport Encryption Implementations

Question: If you are thinking of going to transport agnostic messaging, what approaches are you thinking of taking?

Why?

• While the JWTs and using HTTPS for encryption works nicely for the User-to-Enterprise use case and is easy to get started with (good tooling), it will be challenging in for peer-to-peer messaging.
• It will be challenging to be in alignment with Zero-Trust computing initiatives. In such environments (which will be everywhere), encryption is required for DID Communications (e.g. messages) in transit and at rest. It makes sense to encrypt messages for saving and sending, regardless of the transport.

Proposal: When moving to transport-agnostic encryption, go with JWEs using the DID Doc keys for encryption. Put another way, go with the approach used by Hyperledger Indy and DIF Hub.

Response: If not accepted as a good approach, there was little dissent expressed in the follow on discussion.

Aside: One participant mentioned that they are experimenting with altering the OSI Layer 3 (below Transport) to handle encryption.

Aside: TLS 1.3

• The TLS 1.3 protocol supports the use of DID-type keys, but none of the implementations support it, and adding the support is a requires a non-trivial rewrite that is unlikely to happen any time soon. Further, adoption of TLS 1.3 is still happening relatively slowly.
• Solving the issue with TLS 1.3 would not make the communications transport agnostic, which is at minimum a nice to have, and perhaps required.

Routing

In Hyperledger Indy, routing is done using "forward" messages (aka envelopes).  Forward messages are sent to intermediaries as envelopes with a "To" address for the next recipient and the payload (itself a message) encrypted for the ultimate recipient. This enables an onion-type of routing (envelopes in envelopes...) with intermediaries able to see only enough information to do their job - pass the message along. They cannot see the payload within the envelope they are handling.

The appropriate routing is communicated by the receiver to the sender by a path to each destination agent into the DIDDoc. The sender wraps the message into as many forward envelopes as specified to get the message to it's intended recipient.

Aside

• This routing appoach reminded some in the session about the early days of sendmail and circuit switching networks.
• Note that since this routing is being done at a higher level of the networking stack, this would seem to be more akin to a Software Defined Network (SDN) approach than those no longer used approaches.

Conclusions

While the JWT+HTTPS approach is the right starting point (good tooling, understood model), the reliance of transports for encryption is probably not the best idea in the long term. As other approaches are evaluated, consider the JWE path as it seems to be the best approach.

Additional IIW sessions to be held:

• Kyle Den Hartog on JWEs, making Indy's "almost" JWEs into JWEs and migrating from JWTs+transport encryption to JWEs.