eclipse-edc / Samples

Apache License 2.0
24 stars 48 forks source link

create new policy #279

Open FantZero opened 4 days ago

FantZero commented 4 days ago

provider

i add a DateTimeConstraintFunction: image image image

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

consumer

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

output

the DateTimeConstraintFunction code is not working image

github-actions[bot] commented 4 days ago

Thanks for your contribution :fire: We will take a look asap :rocket:

harnvo commented 4 days ago

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 commented 3 days ago

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

FantZero commented 3 days ago

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 commented 3 days ago

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

FantZero commented 2 days ago

DateTimeConstraintFunction

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

harnvo commented 2 days ago

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 commented 1 day ago

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 commented 1 day ago

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 commented 13 hours ago

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 commented 12 hours ago

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

FantZero commented 11 hours ago

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

ok, i have created the dsc: https://github.com/eclipse-edc/Samples/discussions/285