SSI DIM Wallet Stub can't create Industry Core Policy

[evegufy]

Current Behavior

When EDC contract offers are published with a policy like this, contract negotiation is terminated:

{
    "@context": {
        "odrl": "http://www.w3.org/ns/odrl/2/",
        "cx-policy": "https://w3id.org/catenax/policy/"
    },
    "@type": "PolicyDefinitionRequestDto",
    "@id": "traceability-core",
    "policy": {
        "@type": "odrl:Set",
        "odrl:permission": [
            {
                "odrl:action": "use",
                "odrl:constraint": {
                    "odrl:and": [
                        {
                            "odrl:leftOperand": "https://w3id.org/catenax/policy/FrameworkAgreement",
                            "odrl:operator": {
                                "@id": "odrl:eq"
                            },
                            "odrl:rightOperand": "traceability:1.0"
                        },
                        {
                            "odrl:leftOperand": "https://w3id.org/catenax/policy/UsagePurpose",
                            "odrl:operator": {
                                "@id": "odrl:eq"
                            },
                            "odrl:rightOperand": "cx.core.industrycore:1"
                        }
                    ]
                }
            }
        ]
    }
}

Expected Behavior

Contracts can be negotiated with any usage policy.

Steps To Reproduce

1. Publish EDC asset with the previously mentioned policy (Create EDC asset, policy and contract definition)
2. Start contract negotiation for the contract offer

[evegufy]

@matbmoser @ds-jhartmann Once the description is ready. Please add Nitin, maybe also discuss in the Umbrella Matrix Chat.

Should not be a blocker for the community. Just use empty policies for now.

[matbmoser]

This is related with the policy, because the access policies will be checked against the wallet, and we usually configure the same policy for access and usage.

Why is the stub not accepting things by default???

[ds-jhartmann]

@evegufy I added more details regarding policies.
@matbmoser please add additional information in case I forgot something or got something wrong

[evegufy]

@ds-jhartmann the following error you sent via mail:

SEVERE 2024-11-25T09:42:01.416944841 JerseyExtension: Unexpected exception caught java.lang.NullPointerException: Cannot invoke "Object.toString()" because "v" is null at org.eclipse.edc.iam.identitytrust.service.IdentityAndTrustService.lambda$obtainClientCredentials$0(IdentityAndTrustService.java:114)

Is it related to this issue?

[ds-jhartmann]

@evegufy no, this is not related to the policies

[evegufy]

@nitin-vavdiya could you please give your option on this topic?

[nitin-vavdiya]

Do we have an error log from the SSI stub application?

Do we have what request body is being sent to stub application in the query presentation API call? We are printing the request body in the logs in SSI stub application.

At the current stage, SSI stub application supports only three types of credentials:

1. MembershipCredential
2. DataExchangeGovernanceCredential
3. BpnCredential

If the requested type does not exist in this list, then it will give an error.

For ref:

[evegufy]

@nitin-vavdiya thanks for the quick response!
@matbmoser @ds-jhartmann could you please answer Nitin's questions?

[matbmoser]

@nitin-vavdiya why the usage purpose are not allowed?

[matbmoser]

                    {
                        "leftOperand": "cx-policy:FrameworkAgreement",
                        "operator": "eq",
                        "rightOperand": "DataExchangeGovernance:1.0"
                    },
                    {
                        "leftOperand": "cx-policy:ContractReference",
                        "operator": "eq",
                        "rightOperand": "x12345"
                    },
                    {
                        "leftOperand": "cx-policy:UsagePurpose",
                        "operator": "eq",
                        "rightOperand": "cx.core.industrycore:1"
                    }

Please support this ones

[nitin-vavdiya]

Thanks @matbmoser

Can you please provide a schema/example for these credentials? We need this to prepare credential subject.

We need Catena-X standards references like we have it for framework credentials as mentioned here

[matbmoser]

I have already cleared with the data sov expert group.

There is no credential for the usage purpose.

It is clear written that "any POLICY" the includes Usage Purpose or ContractReference are allowed.

There is not a "credential" to check against, you just just allow it. The rule is that any data consumer and any data provider can specify any data usage purpose constraints. If Catena-X components and data models are used it is required to follow the profile from Catena-X: https://github.com/catenax-eV/cx-odrl-profile/blob/c96b426ded7922f44bdc33bfc5e0bf754031b5e8/profile.md#usagepurpose

Also contract reference shall allow any string.

[matbmoser]

@nitin-vavdiya please enable this two constraints in the policy definition, so that the wallet does not gives an error for them.
Thanks, if you need help tell me ;)

[nitin-vavdiya]

@matbmoser

Thanks for replay.
Wallet stub application neither creating any kind of policy nor doing policy validation in during contract negotiations. This done in EDC control plane. There is no role of wallet stub application.

[lgblaumeiser]

Is there any more log information on what is happening. Actually, @nitin-vavdiya is right, if it fails due to the UsagePurpose, the wallet is not involved. What happens, if the policy only contains one of the two elements, is it accepted?