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
I'm working on a use case where a trusted third party application might inform an OCM server that a resource was shared with it.
This means the Share Creation Notification would not be signed. What do you think?
This means the Share Creation Notification would not be signed. What do you think?
In fact, in #180 I sketched another possible use case that would follow a similar pattern. And in first approximation, we also think not to sign the Share Creation Notification request, in order to keep the "OCM client" logic in that third-party application to the bare minimum - boiling down to sending a single HTTP POST request, as opposed to exposing a /.well-known/ocm endpoint with a public key for the recipient to validate.
In both cases the question I think is "how can we establish that a third party application is trustworthy"? This could be either delegated to the receiver, or via some sort of configured allow-list. Anyhow I think it makes sense to contemplate such scenarios.
Activity
glpatcern commentedon Jun 11, 2025
In fact, in #180 I sketched another possible use case that would follow a similar pattern. And in first approximation, we also think not to sign the Share Creation Notification request, in order to keep the "OCM client" logic in that third-party application to the bare minimum - boiling down to sending a single HTTP POST request, as opposed to exposing a
/.well-known/ocmendpoint with a public key for the recipient to validate.In both cases the question I think is "how can we establish that a third party application is trustworthy"? This could be either delegated to the receiver, or via some sort of configured allow-list. Anyhow I think it makes sense to contemplate such scenarios.