Expected interactions intentionally left out of scope

[elf-pavlik]

Following up on today's discussion. Some interactions we leave intentionally out of scope. Some authentication/authorization related details are still missing, mostly between Resource Server and Subscription Server. I recall previous version having distinct Authorization Server used by both components.

Taking into account #142 we will have (sequence diagrams available at the very bottom of this comment):

• Content Consumer side
  • Discovery Client
  • Subscription Client
  • Notification Receiver
• Content Provider side
  • Resource Server
  • Subscription Server
  • Notification Sender

We define all interactions between the Content Consumer components and Content Provider components. All the details of interactions between components on the same side are left up to implementations.

Assumptions made about internal interactions:

Content Consumer

Discovery Client & Subscription Client

Subscription Client always receives information about Subscription Resources discovered on the Discovery Client.

Discovery Client & Notifications Receiver

When the Discovery Client finds Notification Channels being advertised (on the Description Resource), the Notification Receiver receives information about the discovered Notification Channel directly from the Discovery Client.

Subscription Client & Notifications Receiver

When Notifications Channels are created as a result of a Subscription Request, the Notification Receiver receives information about the custom Notification Channel from the Subscription Client.

Subscription Client always can provide sendTo URI in Subscription Request when request channel using it, while a Notification Receiver will receive sent notifications. Notification Receiver will receive Notification Channel information for all channels using that sendTo, including sender.

Content Publisher

Resource Server & Subscription Server

Resource Server receives information about the available Subscription Services from the Subscription Server, which can be advertised in a Description Resource.

Resource Server & Notifications Sender

When a (Topic) Resource changes, the Notification Sender receives events about these changes from the Resource Server and sends out corresponding notifications on a relevant channel.

Resource Server receives information about pre-established Notification Channels from Notifications Sender, which can be advertised in Description Resource.

Subscription Server & Notifications Sender

The Notification Sender receives from the Subscription Server all the information about all the Notification Channel that it needs, in order to create and send notifications to a given Notifications Receiver.

sequenceDiagram
  participant Discovery Client
  participant Resource Server

  Discovery Client ->> Resource Server: HEAD Resource (topic)
  Resource Server ->> Discovery Client: HTTP Link rel="describedby"
  Discovery Client ->> Resource Server: GET Description Resource
  Resource Server ->> Discovery Client: Description Resource

sequenceDiagram
  participant Subscription Client
  participant Subscription Server

  Subscription Client ->> Subscription Server: Subscription Request
  Subscription Server ->> Subscription Client: Subscription Response (with Notification Channel)

sequenceDiagram
  participant Notification Receiver
  participant Notification Sender

  loop while channel active
    Notification Receiver ->> Notification Sender: Establish connection to the receiveFrom
    Notification Sender -->> Notification Receiver: Stream notifications
  end

sequenceDiagram
  participant Notification Receiver
  participant Notification Sender

  loop while channel active
    Notification Sender ->> Notification Receiver: Send notifications to the sendTo
  end

[elf-pavlik]

For example in SAI Authorization Agent we have Subscription Client using URI Template to mint sendTo and make Subscription Requests for Webhook channels. Later it stores Notification Channel created for that sendTo in Redis. Notifications Receiver later gets that Notification Channel description from Redis when it handles incoming request to sendTo.

In case of WebPush, Notification Receiver will be the Push Service and Subscription Client (in the web browser) will use the Push API to obtain sendTo and other needed information, as well as provide the VAPID key which was discovered in Subscription Resource/Service. Those parts here can actually be specified by channel type since they rely on existing standards.

[CxRes]

@elf-pavlik The purpose of this comment is to serve as a log of changes I make.

• Edited the text to make sure all interactions are in terms of "receive".