An e-commerce offer, which will be available in the future, gets an IRI assigned but the resource isn't created yet.
This IRI to an upcoming e-commerce offer gets advertised in some other resource with the intention that anyone interested in that upcoming offer can subscribe to it and be notified once it becomes available.
Requirement
@CxRes suggested that based on the use case above:
Solid Notifications, should allow (at least not prevent) the creation of channels, where the topic resource doesn't exist yet.
@elf-pavlik questioned this requirement:
Since an IRI already gets allocated to the upcoming e-commerce offer, it seems justified (or even preferable) that the resource describing it already gets created. The description can state the offer as upcoming and doesn't need to include a price or have a way of stating it as TBA.
The use case appears to be possible to support without the suggested requirements.
Security Considerations
@elf-pavlik brought up the requirement of checking access to the resource before creating a channel with it as a topic
It seems insecure, to assume that a newly created resource will use the inherited/default access set on the container it gets created in. If notification channels with were allowed for the topic which doesn't exist yet, the access would need to be re-evaluated after the resource gets created and before Create/Add #183 notification gets set.
Since Solid doesn't support transactions, this could lead to race conditions, since the resource has to be created first, its ACL/ACR discovered afterward, and only then the access policy can be applied. This means that Create/Add notification could be sent before the intended access control gets applied to the created resource.
based on a discussion from the chat https://matrix.to/#/!WdNSKNKuHrHkWppqfn:gitter.im/$VpAK80TomRWlBcZYtFb2aBsPGn04ObP57A4TGgGjguY?via=gitter.im&via=matrix.org
Use Case
@CxRes presented a use case where:
An e-commerce offer, which will be available in the future, gets an IRI assigned but the resource isn't created yet. This IRI to an upcoming e-commerce offer gets advertised in some other resource with the intention that anyone interested in that upcoming offer can subscribe to it and be notified once it becomes available.
Requirement
@CxRes suggested that based on the use case above:
Solid Notifications, should allow (at least not prevent) the creation of channels, where the
topicresource doesn't exist yet.@elf-pavlik questioned this requirement:
Since an IRI already gets allocated to the upcoming e-commerce offer, it seems justified (or even preferable) that the resource describing it already gets created. The description can state the offer as upcoming and doesn't need to include a price or have a way of stating it as TBA.
The use case appears to be possible to support without the suggested requirements.
Security Considerations
@elf-pavlik brought up the requirement of checking access to the resource before creating a channel with it as a
topicIt seems insecure, to assume that a newly created resource will use the inherited/default access set on the container it gets created in. If notification channels with were allowed for the
topicwhich doesn't exist yet, the access would need to be re-evaluated after the resource gets created and before Create/Add #183 notification gets set. Since Solid doesn't support transactions, this could lead to race conditions, since the resource has to be created first, its ACL/ACR discovered afterward, and only then the access policy can be applied. This means that Create/Add notification could be sent before the intended access control gets applied to the created resource.