Announcing enmeshed v2 Requests

This is one of the blog posts regarding enmeshed v2. For an overview of all enmeshed v2 blog posts, please refer to the enmeshed v2 announcement blog post.

This blog post requires a superficial understanding of the new Attribute handling. Please refer to the corresponding blog post to learn more about it if you are not yet familiar with it.

This blog post describes what Requests are in the enmeshed universe and how they are used to exchange Attributes and establish Relationships.

When we mention “the App” or “the Connector” in this blog post, we mean the official enmeshed App and enmeshed Connector.

Keep in mind that we cannot describe all details in this blog post. Refer to the V2 documentation for further information about how Requests are working “under the hood”.

Requests

Requests in enmeshed always defined a way to exchange structured data. In enmeshed V1 this was exclusively about exchanging structured Attributes with its AttributesChangeRequest and AttributesShareRequest. In V1 there also was no defined response structure, as well as no track record of Requests and their status. Thus, V1 Requests were quite limited.

Requests in V2 extend the Request featureset by providing more structured Requests, as well as Requests for unstructured data. Additionally, they are not fixed to the Identitity’s Attributes. One example is a form you can send to a User, which contains some questions in natural language, which does not affect the Attributes. Another example is a Multi-Factor-Authentication Request which might be available in the future.

In enmeshed V1 RelationshipTemplates and RequestMails each defined their own way for exchanging Attributes. Further only the App could process them. When integrating via the Connector you had to manually process all Requests. For V2 we pulled the Request handling from the User-Experience Layer to the Consumption layer. This enabled us to provide you with an API in the Connector to work with Requests. It also helped us making Request handling more flexible and easier to use.

Exchanging Requests

The simplest way to exchange Requests is using Messages. But for sending Messages a Relationship is required. To create a Relationship we also wanted the possiblity to exchange Requests with the same structure.

Relationships and RelationshipTemplates

The flow for establishing a Relationship between the App and another App or Connector has changed significantly. The body of the RelationshipTemplate is now a strict type that can be processed by the App and the Connector. It looks as follows:

interface RelationshipTemplateContent {
  "@type": "RelationshipTemplateContent";
  title?: string;
  metadata?: object;
  onNewRelationship: Request;
  onExistingRelationship?: Request;
}

More about the structure of a Request will follow in the V2 documentation.

When the RelationshipTemplate is scanned by the App, the Request (defined by the creator of the RelationshipTemplate) is rendered for the User. This is similar to the flow in V1. The App will then automatically create the Relationship when the User accepts the Request.

Messages

Messages can now be used to exchange the same Requests that are used to enter a Relationship. A Message can now simply contain the content { "@type": "Request", ... } or { "@type": "Response", ... }. The RequestMail, AttributesChangeRequest and AttributesShareRequest types are now deprecated and will be removed in the future. Because the enmeshed V2 App will stop processing these types we strictly advise against further using them.

So far, only one Request can be sent with one Message. This is intentional, as with RequestItemGroups and RequestItems, various data or actions can be requested. If there is the need to submit multiple Requests, send multiple Messages.

Modules managing Requests

The main component powering the enmeshed App and the enmeshed Connector is the Runtime. The Runtime is modular and we decided to use this to provide two Modules for managing Requests: the Request Module and the Decider Module.

The Decider Module is in its early stages and we will inform you about it in the future.