Automatic ODRL Policy Template Validation

[jjeroch]

Summary

The policy hub is planning to introduce a new feature called "automatic odrl policy template validation". This feature will allow users or systems to submit ODRL Policy Templates to the policy hub via the REST API. The policy hub will then validate the correctness of the template and provide a response to the user or system.

The possible responses from the policy hub include:

• All Correct: Indicates that the template is correct and no issues were found.
• Format correct but not supported values are used: Indicates that the template has the correct format, but some values used are not supported. Examples of unsupported values include "String", "String", and "String".
• Format correct but not supported policyRules are used: Indicates that the template has the correct format, but some policyRules used are not supported. Examples of supported string values include
  • "Business Partner Number rightOperand incorrect"
  • "Inactive Frameagreement Version used"
  • etc.

Please note that the policy hub can provide additional responses beyond the ones mentioned above.

Note - a similar implementation exists inside the authority & schema registry - please check the implementation details and likely use similar logic for the policy hub scenario. More information can be found at [this link](https://github.com/eclipse-tractusx/ssi-authority-schema-registry/issues/11).

To support all scenarios the response should never be a html error response. Instead we need an actual Payload information response to the user.

{
"Status": "string - either "OK", "OK under conditions", "NOK""
"Details": [
  {
   "line": "rowxx",
   "message": "string"
   }
 ]
}

---

Acceptance Criteria

• Implementation done
• Pull request created
• Pull request reviewed and merged
• Deployment to dev environment
• Running tests on dev environment
• Creation/update of documentation

---

Standard ODRL Structure expected

{
    "@context": {
        "@vocab": "https://w3id.org/edc/v0.0.1/ns/"
    },
    "@id": "<POLICY-ID>",
    "policy": {
        "@context": [
            "https://www.w3.org/ns/odrl.jsonld",
            {
                "cx-policy": "https://w3id.org/catenax/policy/"
            }
        ],
        "@type": "Policy",
        "profile": "cx-policy:profile2405",
        "permission": [
            {
                "action": "use",
                "constraint": {
                    "and": [
                        {
                            "leftOperand": "cx-policy:FrameworkAgreement",
                            "operator": "eq",
                            "rightOperand": "traceability:1.0"
                        },
                        {
                            "leftOperand": "cx-policy:ContractReference",
                            "operator": "eq",
                            "rightOperand": "<individual contract-id>"
                        },
                        {
                            "leftOperand": "cx-policy:UsagePurpose",
                            "operator": "eq",
                            "rightOperand": "cx.core.industrycore:1"
                        }
                    ]
                }
            }
        ]
    }
}

---

Validation Rules

• actions must be set; either "use" or "access", flag any others as unsupported
• Validate that "use" actions are paired with "and" logical constraints.
• "access" actions can be paired with "and" or "or" logical constraints
• Mark "xone" or "andSequence" logical constraints as "OK under conditions", noting that while semantically correct, they are not supported by CX.
• Ensure validation is case-insensitive.
• Restrict operators to "eq", "in", and "or", providing guidance on unsupported operators.
• Operators such as "gt", "gteq", "lt", "lteq", "neq", "isA", "hasPart", "isPartOf", "isAllOf", "isAnyOf", "isNoneOf" are used; response needed that those are "OK under conditions"; but not suggested to be used in CX context.
• Permit only specific leftOperands, and flag any others as unsupported. Supported are:
  • cx-policy:Membership
  • cx-policy:BusinessPartnerNumber
  • cx-policy:ContractReference
  • cx-policy:FrameworkAgreement
  • cx-policy:UsagePurpose
• Check the validity and activity status of rightOperands. The used rightOperand must be allowed and in "active" statue
  • if a none active rightOperand is used provide specific response of the incorrect use of an inactive rightOperand
  • If a not supported rightOperand is used - provide the specific response as well

[evegufy]

@MaximilianHauer is this issue still relevant for the 24.12 implementation?

cc: @Phil91

[MaximilianHauer]

version removed. currently discussion ongoing regarding oldr.

[MaximilianHauer]

@DanielaWuensch i assume we should track this topic in regards of the TAP 7.6 ?