N-times usage policy implementation

[carlosperezdengra777]

Question: Implementing a usage-based access policy in EDC

Hello,

I'm currently working on a custom policy evaluation function that restricts access to an asset once it has been used more than N times (e.g., N successful transfers). I'm following the recommended pattern by:

• Defining the policy constraint in resources/<...>/extensions.policy
• Registering it via a PolicyFunctionsExtension class
• Implementing a UsageCountConstraintFunction that retrieves the number of completed transfers for a given assetId

My function currently tries to call the /transferprocesses/request API to count how many completed transfers exist for a given asset:

private int getCompletedTransferCount(String assetId) {
    try {
        URL url = new URL("http://localhost:29193/management/v3/transferprocesses/request");
        HttpURLConnection conn = (HttpURLConnection) url.openConnection();
        conn.setRequestMethod("POST");
        conn.setRequestProperty("Content-Type", "application/json");
        conn.setDoOutput(true);

        String body = "{\"filterExpression\":[{\"operandLeft\":\"assetId\",\"operator\":\"=\",\"operandRight\":\"" + assetId + "\"}]}";
        conn.getOutputStream().write(body.getBytes());

        Scanner scanner = new Scanner(conn.getInputStream());
        StringBuilder json = new StringBuilder();
        while (scanner.hasNext()) json.append(scanner.nextLine());
        scanner.close();

        return json.toString().split("\"state\"\\s*:\\s*\"COMPLETED\"").length - 1;
    } catch (IOException e) {
        return 0;
    }
}

However, the evaluation function is not triggered or doesn't behave as expected — I don't see it being logged even when policies are evaluated during negotiation. Regarding this topic, I have a few questions:

1.- Is it correct to assume that the number of "accesses" means the number of completed transfer processes, and not just contract negotiations?

2.- Is there a supported or recommended way to access assetId and connectorId inside the evaluation function during contract negotiation?

3.- I tried context.getContextData(...) but those values are not available at that point — as expected.

4.- I noticed that the sample LocationConstraintFunction uses claims configured externally (e.g., via the participant agent). Is this the only reliable way to inject dynamic context values into the policy evaluation at negotiation time?

5.- Finally, is calling an external API like /transferprocesses/request inside a policy evaluation function considered an anti-pattern? Or is there a more idiomatic way in EDC to query internal transfer state for policy logic?

Thank you very much in advance — any guidance, clarification or examples are greatly appreciated!

Similar questions have been related: #4032, but do not satisfy the reason of the consultation.

[paullatzelsperger]

@carlosperezdengra777 any reason why you reopened the exact same discussion as #5000 again?

[carlosperezdengra777]

Someone told that 'General' may not be the right forum or could be a discussion that would even fit better at the Discord channel. Consequently, I closed the previous #5000.

[jimmarino]

Transfer processes do not necessarily mean the number of times a particular asset has been accessed or downloaded. It depends on how data access is modelled. Also, you should go back over the documentation to understand the relationship between a transfer process, a contract agreement, and a contract negotiation.

To be honest, this use case seems contrived. What are you trying to achieve?

[carlosperezdengra777]

Thank you for the clarification — you're right. I'm reviewing the documentation again with that in mind.

To clarify the use case:

We're experimenting with enforcing usage-based access control, specifically, limiting how many times a particular asset can be accessed (e.g., "this dataset can only be retrieved 3 times"). The goal is to enforce business constraints for certain data products that have limited usage terms or licensing restrictions.

I understand that a transfer process doesn't necessarily map 1:1 with an actual download or access event. But in a minimal viable implementation, we're treating a successful transfer (state = COMPLETED) as a proxy for a data access. That’s why we were counting completed transfer processes per asset.

Simplifying:
What we’re really intend to implement is a policy that prevents an asset from being downloaded or accessed more than N times.

So the main questions become:

• Is this kind of logic (i.e., max number of accesses/downloads) something that fits into the existing policy engine and policy scopes (e.g., 'contract.negotiation', 'transfer.process')?
• Or should we instead be looking at an external mechanism — such as a transfer listener or a custom enforcement point — to enforce this type of usage limit?

Thanks again for the feedback.

[jimmarino]

Enforcing limits like this can be difficult, if not impossible, for some cases:

• It's easy to enforce access to an API - use a counter for each invocation.
• A download counter is nearly impossible if no download agent exists on the client. For example, how would the data plane know that a file or set of files was successfully downloaded without some checksum that can be verified on the client?

I would not use the control plane as a counter because you then introduce a backward dependency on it from the data plane. Have the data plane count the number of times a resource is accessed (assuming that is even possible to do in a reliable way) and update a persistent counter and expiration marker. The data plane checks the expiration marker on each access. You can also create a custom policy bound to the transfer process policy scope that checks expiration marker when a new TP is opened.

I would think about modelling this in a different way for the reasons mentioned above. For example, create an access policy for a time duration instead.