create new policy

[FantZero]

provider

i add a DateTimeConstraintFunction:

The code indicates that when consumer performs contractnegotiation, the date precedes the datatime

consumer

the negotiate-contract.json and the consumer-configuration.properties:

output

the DateTimeConstraintFunction code is not working

[github-actions]

Thanks for your contribution 🔥 We will take a look asap 🚀

[harnvo]

Adding permission in policy is not written in tutorial, and therefore following the tutorial should fail.

By looking at the source code, I found how the policy engine checks if the two policies are equal.

Simply put, the policy in create-policy.json should be keep identical to the policy in negotiate-contract.json (except for @id, assignee and target). In your case, your negotiate-contract.json should be changed to:

{
"@context": {
    "@vocab":"https://w3id.org/edc/ve.0.1/ns/"
    },
"@type": "ContractRequest",
"counterPartyAddress":"http://localhost:19194/protocol",
"protocol":"dataspace-protocol-http",
"policy":{
    "@context":"http://www.w3.org/ns/odrl.jsonld",
    "@id":“MQ==:YXNZZXRJZA==:Y2NkM2Y0Zj0tYzAyMi00MmZiLTlhZTYtOThhNGQ3M2Y3Yj04",
    "@type":"Offer",
    "assigner":"provider",
    "target":"assetId",
    permission":[YOUR_PERMISSION_HERE]
}

[FantZero]

I copied the permission section of create-policy.json into negotiate-contract.json, but it didn't work

[FantZero]

Adding permission in policy is not written in tutorial, and therefore following the tutorial should fail.

By looking at the source code, I found how the policy engine checks if the two policies are equal.

Simply put, the policy in create-policy.json should be keep identical to the policy in negotiate-contract.json (except for @id, assignee and target). In your case, your negotiate-contract.json should be changed to:

{
"@context": {
    "@vocab":"https://w3id.org/edc/ve.0.1/ns/"
    },
"@type": "ContractRequest",
"counterPartyAddress":"http://localhost:19194/protocol",
"protocol":"dataspace-protocol-http",
"policy":{
    "@context":"http://www.w3.org/ns/odrl.jsonld",
    "@id":“MQ==:YXNZZXRJZA==:Y2NkM2Y0Zj0tYzAyMi00MmZiLTlhZTYtOThhNGQ3M2Y3Yj04",
    "@type":"Offer",
    "assigner":"provider",
    "target":"assetId",
    permission":[YOUR_PERMISSION_HERE]
}

I copied the permission section of create-policy.json into negotiate-contract.json, but it didn't work~ :(

[harnvo]

I don't see a problem here. The log shows provider is evaluating the policy constraint, and agreed to the contract, right?

[FantZero]

DateTimeConstraintFunction

DateTimeConstraintFunction code of no effect, the inside of the log without printing.

[harnvo]

DateTimeConstraintFunction code of no effect, the inside of the log without printing.

If I have understood everything correctly, contract-negotiation only ensures that the provider and consumer have reached an agreement. During this phase provider does not validate the claims made by consumer. So this should be an expected behavior.

It is more like how we are reading terms and conditions when we are downloading softwares. By clicking the agree button it only means you agree with the policy. The Identity validation is what should happen afterwards.

You may cross-validate with someone else in case I have some wrong understandings.

[FantZero]

DateTimeConstraintFunction code of no effect, the inside of the log without printing.

If I have understood everything correctly, contract-negotiation only ensures that the provider and consumer have reached an agreement. During this phase provider does not validate the claims made by consumer. So this should be an expected behavior.

It is more like how we are reading terms and conditions when we are downloading softwares. By clicking the agree button it only means you agree with the policy. The Identity validation is what should happen afterwards.

You may cross-validate with someone else in case I have some wrong understandings.

Here's the problem: provider sets dateTime before 2024-07-01 in the create-policy.json, and consumer sets edc.mock.dateTime=2024-06-30 in consumer-configuration.properties. It appears that the authentication will pass, but the log print fails the verification

[harnvo]

Here's the problem: provider sets dateTime before 2024-07-01 in the create-policy.json, and consumer sets edc.mock.dateTime=2024-06-30 in consumer-configuration.properties. It appears that the authentication will pass, but the log print fails the verification

Please provider extra information (what command you used in terminal, what is the exact log print). Better in markdown format instead of pics.

---

Maybe a bit off topic, but I believe including date-time info in consumer's claims is not a desirable implementation.

Claims should only include what is relevant to one's identity (and this is why we need an identity provider), which does not include date-time (after all, everyone on Earth share the same time).

If I were you, I would consider letting provider to check the date, but not the identity provider.

[FantZero]

Here's the problem: provider sets dateTime before 2024-07-01 in the create-policy.json, and consumer sets edc.mock.dateTime=2024-06-30 in consumer-configuration.properties. It appears that the authentication will pass, but the log print fails the verification

Please provider extra information (what command you used in terminal, what is the exact log print). Better in markdown format instead of pics.

Maybe a bit off topic, but I believe including date-time info in consumer's claims is not a desirable implementation.

Claims should only include what is relevant to one's identity (and this is why we need an identity provider), which does not include date-time (after all, everyone on Earth share the same time).

If I were you, I would consider letting provider to check the date, but not the identity provider.

I'm sorry, but this date-time case is really not a desirable implementation. My original intention is to simulate the existing location example and expand the implementation of another policy.
Perhaps I should mention that the policy is that the consumer is not allowed to download the original data. Could you give me some suggestions to implement the above policy

[harnvo]

Would you mind opening a new discussion in discussion page? As this is beyond the scope of issue.

[FantZero]

Would you mind opening a new discussion in discussion page? As this is beyond the scope of issue.

ok, i have created the dsc: #285

[github-actions]

This issue is stale because it has been open for 14 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 7 days since being marked as stale.