You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 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
Loading
sequenceDiagram
participant Notification Receiver
participant Notification Sender
loop while channel active
Notification Sender ->> Notification Receiver: Send notifications to the sendTo
end
Loading
The text was updated successfully, but these errors were encountered:
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.
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):
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.
The text was updated successfully, but these errors were encountered: