MembershipCredential question

[thomasrutger]

In the readme, under 3.3 Access control the following is stated:

In addition, it is a dataspace rule that the MembershipCredential must be presented in every DSP request. This
credential attests that the holder is a member of the dataspace.

My understanding currently is that while the scopes are mapped using DefaultScopeMappingFunction and they are retrieved on the provider side for any request, it is only checked if there is a credential of type MembershipCredential. It does not verify the claims of that credential, for instance, if the "since" claim is not somewhere in the future. Therefore, you still need to attach the right policy to every asset to make sure that MembershipCredentialEvaluationFunction is evaluated.

Is this understanding correct?

If so, would it be a good idea to make a policy like the following to make sure that it is automatically activated for every asset?

{
  "@context": [
    "https://w3id.org/edc/connector/management/v0.0.1"
  ],
  "@id": "require-membership",
  "@type": "ContractDefinition",
  "accessPolicyId": "require-membership",
  "contractPolicyId": "require-membership",
  "assetsSelector": []
}

[paullatzelsperger]

Long-winded answer

When a policy contains a constraint where the leftOperand that can be mapped to a VC, then the corresponding scope is constructed and attached to the access token. This mapping is done using a ScopeExtractor, e.g. the DataAccessCredentialScopeExtractor.

The problem we're facing though is the Catalog request, because it is the primordial request, and there is no prior interaction history, so there is no way for the provider to tell the consumer that it expects a MembershipCredential. The only remedy for that is to either attach the MembershipCredential in every DSP request, or specifically in the Catalog request.

Once this is done, the consumer knows he must send the membership VC, and the provider knows he must evaluate it during catalog resolution. If that didn't happen, the consumer wouldn't know that an access token for the membership VC needs to be attached, and the accessPolicy could never be fulfilled.

If what you're after is to evaluate both the MembershipCredentialEvaluationFunction and the DataAccessLevelFunction during contract negotiation, then you could just write a policy that contains two constraints:

{
    "@context": [
        "https://w3id.org/edc/connector/management/v0.0.1"
    ],
    "@type": "PolicyDefinition",
    "@id": "require-membership-and-dataaccess",
    "policy": {
        "@type": "Set",
        "obligation": [
            {
                "action": "use",
                "constraint": {
                    "leftOperand": "MembershipCredential",
                    "operator": "eq",
                    "rightOperand": "active"
                }
            },
            {
                "action": "use",
                "constraint": {
                    "leftOperand": "DataAccess.level",
                    "operator": "eq",
                    "rightOperand": "processing"
                }
            }
        ]
    }
}

and reference it in the contract definition:

{
    "@context": [
        "https://w3id.org/edc/connector/management/v0.0.1"
    ],
    "@id": "member-and-dataprocessor-def",
    "@type": "ContractDefinition",
    "accessPolicyId": "require-membership",
    "contractPolicyId": "require-membership-and-dataaccess",
    "assetsSelector": {
        "@type": "Criterion",
        "operandLeft": "https://w3id.org/edc/v0.0.1/ns/id",
        "operator": "=",
        "operandRight": "asset-1"
    }
}

(BTW the JSON you posted is a contract def, not a policy def :))

TL;DR

whenever you want the membership function to be evaluated, a constraint must exist in the respective policy

[thomasrutger]

Thanks for the extensive answer. This does clarify things.

One more thing. Is there a reason for using odrl:obligation instead of odrl:permission?

[paullatzelsperger]

in this case here, not really. I can't remember exactly, but I think I merely wanted to demonstrate how to write policy functions for different rule types.

[paullatzelsperger]

oh and just for the sake of completeness, you can also link constraints together logically with an or or an and, for example:

{
  "@context" : [ "https://w3id.org/edc/connector/management/v0.0.1" ],
  "@type" : "PolicyDefinition",
  "@id" : "some-policy-id",
  "policy" : {
    "@type" : "Set",
    "obligation" : [ ],
    "permission" : {
      "action" : "use",
      "constraint" : {
        "and" : [ {
          "leftOperand" : "inForceDate",
          "operator" : "gteq",
          "rightOperand" : "contractAgreement+0s"
        }, {
          "leftOperand" : "inForceDate",
          "operator" : "lteq",
          "rightOperand" : "contractAgreement+10s"
        } ]
      }
    },
    "target" : "assetId",
    "prohibition" : [ ]
  }
}

(example taken from here, it's the toString representation of inputObject)