Re: ODRL Profile using Verifiable Credential

Not sure I follow your use case – is the policy:
over an asset that is a “verified credential” that will have a refinement?
refining the types of assignees whilst making use of a verified credential as the input?
 

 
First of all, I just want to point out that this ODRL profile is not only intended for constraints on location only, but any kind of Verifiable Credential claim.
Not sure I follow
a. I am not sure I understand your whole point so feel free to correct me, in this case I used the "Assignee" to make it very clear that the constraint on the verifiable credential claim apply on the recipient of the rule, the requirement of this property comes bottom up, meaning that an ovc:constraint must be defined on this property; maybe it might be better to redefine an "ovc:offer" and make it required then.
Your example uses an assignee ambiguously, the code uses "$.credentialSubject.gx:legalAddress.gx:countrySubdivisionCode" as a odrl:LeftOperand  (not the same as odrl:leftOperand) 
Not sure why you override every odrl: with ovc: (the ttl file doesn’t give much detail)
Not sure what "ovc:credentialSubjectType": "gx:LegalParticipant" does (see the structure of a constraint, they are ‘almost’ arithmetic, I interpret your JSON like:
outcome =  location isAnyOf [ "FR-HDF","BE-BRU"], LegalParticipant

                        the ‘LegalParticipant’ is not participating semantically on the operation, and your ovc:constraint definition doesn’t define what’s its role?
b. Yes indeed, I will replace the operator used in that example, it should rather be "isAnyOf"
excellent
 
For the ISO-3166-2, it is rather defined on the shapes of the crendential the policy is referring to (and it is just to illustrate the physical location only), another possible way is to add a unit to the constraint
That first link just sent me to a large JSON file 😊
 
As for the ovc:leftOperand, it refers to the JSONPath specification, since JSON-LD is widely used in Verifiable Credentials and many libraries are available for a technical implementation
Sorry, not what I meant … there are 2 different terms:
https://www.w3.org/TR/odrl-vocab/#term-leftOperand 
https://www.w3.org/TR/odrl-vocab/#term-LeftOperand
Meaning your expressions should look like:

<:LeftOperand> [ absolutePosition, absoluteSize, absoluteSpatialPosition, absoluteTemporalPosition, count, dateTime, delayPeriod, deliveryChannel, device, elapsedTime, event, fileFormat, industry, language, media, meteredTime, payAmount, percentage, product, purpose, recipient, relativePosition, relativeSize, relativeSpatialPosition, relativeTemporalPosition, resolution, spatial, spatialCoordinates, system, systemDevice, timeInterval, unitOfCount, version, virtualLocation ] <- new operands inherit from :LeftOperand

<:Operator> [ eq, gt, gteq, hasPart, isA, isAllOf, isAnyOf, isNoneOf, isPartOf, lt, lteq, neq ]

<:RightOperand> <- here you define a class, then you instantiate accordingly the values you want to ‘test’

:leftOperand <:LeftOperand>

:operator <:Operator>

:rightOperand <:RightOperand>

You also have to consider the :LogicalConstraint class as part of your constraint:

 

                        [ :spatial :isAnyOf [ "GB", "DE", "FR", ] 

                        :and

                        [ :purpose :eq "rent" ]

                        :and

                        [ :media :eq "some definition" ]

                        :and

                        [ :periodCoverage :lt "some time value" ]

 

and you have the unary operators :xone and :andSequence:

:xone [

                         [ :deliveryChannel :eq "value 1" ],

                         [ :deliveryChannel :eq "value 2" ],

                         [ :deliveryChannel :eq "value 3" ],

                         [ :deliveryChannel :eq "value 4" ]

                        ]

 

 

 

From: Yassir Sellami <yassir.sellami@gaia-x.eu>
Date: Friday 1 March 2024 at 09:01
To: Joshua Cornejo <josh@marketdata.md>
Cc: "public-odrl@w3.org" <public-odrl@w3.org>
Subject: Re: ODRL Profile using Verifiable Credential
Resent-From: <public-odrl@w3.org>
Resent-Date: Fri, 01 Mar 2024 09:01:15 +0000

 

Hello Joshua,

 

Thank you for taking the time to go through the profile and getting back with your feedback.

 

First of all, I just want to point out that this ODRL profile is not only intended for constraints on location only, but any kind of Verifiable Credential claim.

 

a. I am not sure I understand your whole point so feel free to correct me, in this case I used the "Assignee" to make it very clear that the constraint on the verifiable credential claim apply on the recipient of the rule, the requirement of this property comes bottom up, meaning that an ovc:constraint must be defined on this property; maybe it might be better to redefine an "ovc:offer" and make it required then.
b. Yes indeed, I will replace the operator used in that example, it should rather be "isAnyOf"
For the ISO-3166-2, it is rather defined on the shapes of the crendential the policy is referring to (and it is just to illustrate the physical location only), another possible way is to add a unit to the constraint
As for the ovc:leftOperand, it refers to the JSONPath specification, since JSON-LD is widely used in Verifiable Credentials and many libraries are available for a technical implementation
 

 

Best regards,

Yassir SELLAMI

From: Joshua Cornejo <josh@marketdata.md>
Sent: Thursday, February 29, 2024 12:14
To: Yassir Sellami <yassir.sellami@gaia-x.eu>
Cc: public-odrl@w3.org <public-odrl@w3.org>
Subject: Re: ODRL Profile using Verifiable Credential 

 

I missed another one as I pressed send:

 

"ovc:leftOperand": "$.credentialSubject.gx:legalAddress.gx:countrySubdivisionCode",

 

 

I checked your repository: https://gitlab.com/gaia-x/lab/policy-reasoning/odrl-vc-profile/-/raw/main/ovc-1.ttl

 

I couldn’t find if that text in bold that you are defining descends from odrl:LeftOperand ? 

 

I also believe it overlaps/overrides odrl:leftOperand odrl:spatial ?

 

 

From: Joshua Cornejo <josh@marketdata.md>
Date: Thursday 29 February 2024 at 10:43
To: Yassir Sellami <yassir.sellami@gaia-x.eu>
Cc: "public-odrl@w3.org" <public-odrl@w3.org>
Subject: Re: ODRL Profile using Verifiable Credential
Resent-From: <public-odrl@w3.org>
Resent-Date: Thu, 29 Feb 2024 10:43:29 +0000

 

Hi Yassir,

 

      "assignee": {

        "ovc:constraint": [

          {

            "ovc:leftOperand": "$.credentialSubject.gx:legalAddress.gx:countrySubdivisionCode",

            "operator": "http://www.w3.org/ns/odrl/2/in",

            "rightOperand": [

              "FR-HDF",

              "BE-BRU"

            ],

            "ovc:credentialSubjectType": "gx:LegalParticipant"

          }

        ]

      }

 

A couple of comments on the code:

 
Assignee
You’re defining an Offer (says nothing about mandatory Assignee – so I assume it could go there)

According to the definition: “The Party is the recipient of the Rule.”  

In your example, you seem to be using it as a category/type. I had the same conceptual problem and it is something that I have on my “list” of questions for v3.0.

 

In my interpretation - it is possible that the term ‘Collection’ could be used orthogonally – to define a “collectionOf” where the origins allow for ‘basket categories’ that would filter down to apply constraints when you transform an Offer -> Agreement (in your case: you want to restrict to a physical location). And also “partOf”, where you have a consortium (e.g. Sony) with multiple organisational divisions of types (“collectionOf”) in different locations (to apply your constraint).

 
Operators
 

https://www.w3.org/TR/odrl-vocab/#constraintRelationalOperators

 

“in” is not an (active) operator, I think you are referring to:

 

http://www.w3.org/ns/odrl/2/isAnyOf

 

 

And a separate thought:

 

Having ISO 3166 as separate attributes/operands/elements for constraints will prove to be more convenient (if you are expecting third parties to consume your policies).

Regards,

 

From: Yassir Sellami <yassir.sellami@gaia-x.eu>
Date: Thursday 29 February 2024 at 09:40
To: "public-odrl@w3.org" <public-odrl@w3.org>
Subject: ODRL Profile using Verifiable Credential
Resent-From: <public-odrl@w3.org>
Resent-Date: Thu, 29 Feb 2024 09:40:02 +0000

 

Hello,

 

I am happy to share with you this ODRL Profile for Attribute based access/usage control using Verifiable Credential claims.

 

Here are some useful links on the ODRL Profile:

The ODRL Profile (a specification document and a .ttl definition):  https://gitlab.com/gaia-x/lab/policy-reasoning/odrl-vc-profile

Also available through: https://w3id.org/gaia-x/ovc/1/

An open-source demonstration tool is available (not all features are implemented): https://wizard.lab.gaia-x.eu/policyStepper

 

I am looking forward to hearing any feedback from you.

 

Feel free to reach out for any questions or contributions.

 

Best regards,

Yassir Sellami | Software Developer
Gaia-X European Association for Data and Cloud AISBL

yassir.sellami@gaia-x.eu  | www.gaia-x.eu |  

Avenue des Arts 6-9
1210 Bruxelles/Brussels

Belgium

News & Press | Events | Media| Membership | www.gaia-x.eu

PRIVACY AND CONFIDENTIALITY NOTICE: For details about what personal information we collect and why, please see our Privacy Policy on our website at http://www.gaia-x.eu/privacy-policy.

This e-mail message and any attachments are for the sole use of the intended recipient(s) and may contain confidential and/or legally privileged information. Any unauthorized use or disclosure, copying and/or distribution of the content of this e-mail message and attachments is prohibited. If you are not the intended recipient, please contact us by reply e-mail and destroy all copies of the original message and attachments immediately. Thank you.

Please consider the environment before printing this e-mail. Save about 200ml water, 2g CO2, 0.05kWh power, and 2g wood.

Received on Friday, 1 March 2024 09:39:38 UTC