I want to kindly ask to give feedback regarding the following proposal:
Example snippet from the catalog example:
"odrl:hasPolicy": [
{
"@context": {
"@vocab": "https://www.w3.org/TR/odrl-model/"
},
"@id": "urn:uuid:2828282:3dd1add8-4d2d-569e-d634-8394a8836a88",
"permission": [
{
"action": "use",
"constraint": [
{
"leftOperand": {
"@value": "spatial"
},
"rightOperand": {
"@value": "EU"
},
"operator": "EQ"
}
],
"duty": []
}
],
"prohibition": [],
"obligation": []
}
],
https://raw.githubusercontent.com/International-Data-Spaces-Association/ids-specification/71f06f718147f12a4d333e9a9e604d13944882b1/catalog/message/catalog.json
Since this is very redundant, because many of those policies / offers are very similar, I think it would be also allowed to use IDs as a reference instead of the entire node of the object, meaning:
"odrl:hasPolicy": [
{
"@type": "odrl:Offer",
"@id": "https://provider.com/edc/offer/1",
},
{// next possible policy }
],
At least that is my - still limited - understanding of:
https://www.w3.org/TR/vocab-dcat-3/#conformance
Additional constraints in a profile MAY include:
Controlled vocabularies or IRI sets as acceptable values for properties
and if this is the case, I would even slightly change the id of the policy and make it a "content addressable storage" by using the hash of the policy itself (as a URL) to reference it. So it would look like:
"odrl:hasPolicy": [
{
"@type": "odrl:Offer",
"@id": "https://provider.com/policies/cdfd26aaf5b1fdc6d71af7c1349869f9314b67626bc1eec44e64af674e357eed",
},
{// next possible policy }
],
where the cdfd26aaf5b1fdc6d71af7c1349869f9314b67626bc1eec44e64af674e357eed
is a sha256 hash of the policy itself. Serialization / canonicalization details need to apply of course.
That means there would be a new endpoint containing all possible policies: a policy repository
under /policies/{hash}
The only way that this is possible at all, is because of the separate profile which says:
https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/catalog/catalog.protocol.md#5-dcat-and-odrl-profiles
Each ODRL Offer must NOT include an explicit target attribute.
because hashing the policy WITH a target
wouldn't work :-)
The advantages would be:
- Reduce data transfer, assuming many datasets use the same policy
- Reduce processing overhead (on both sides, but mainly) on the consumer side, because it's immediately clear whether the policy is already known and can be accepted (allow-listed policies...)
- uniqueness of policies may allow some further optimizations during the flow
Possible DISadvantages:
- Are policies protected content already? And is the hash 'unique' enough to 'protect' its content? Further access control could be applied, too, but probably is not worth it. I guess it's better to add the full policy to the dataset instead of a reference if there are concerns. Can be decided per dataset of course.
Any thoughts on this?