ACP: operational semantics of "propagated"?

[bblfish]

In the current specs the word "propagated" is used a lot. Looking at Definitions the word is used, but there is no operational semantics attached to it. Is some information copied to the created resources? Is it linked to?

So in 2.1.1 Control Access of the use cases, the following is added to the ACR of the root container.

<>
  acp:access :podControl ;
  acp:accessMembers :podControl .

<#myPodAccess>
  a acp:AccessControl ;
  acp:applyConstant :podControl ;
  acp:applyMembersConstant :podControl .

(see issue 31 re applyConstant).

But in the rest of the examples we never see a GET on the ACR resources that are created with new contents of a container, so we don't know what is meant to appear there when a resource is created.

I assume that a link to the policies is created in each ACR, so that clients can find out by following their nose what the access rules are.

In that case how would a client know what statements in an ACR can be edited and which ones cannot?

[emmettownsend]

Firstly I must apologise that applyConstant no longer exists. It was replaced with applyProtected and applyLocked. I'll have to update the docs to remove that.

your statement below is correct "I assume that a link to the policies is created in each ACR, so that clients can find out by following their nose what the access rules are."

"In that case how would a client know what statements in an ACR can be edited and which ones cannot? "

In answer to that question there are two scenarios. If the policy is contained in the ACR itself and the agent has write permission as a result of the policies specified using acp:access then they can then they can edit that policy.

If however the policy is in a separate resource (which would be the case if the policy was propagated by the server as a result of applyMembers) then they would need write access on the ACR associated with the resource in which the policy is contained in order to have permission to edit that policy.

When it comes to permissions to edit statements in a given ACR there are three scenarios 1- The statement uses acp:apply. If the agent has write access as a result of the policies specified using acp:access then they can edit the acp:apply and acp:applyMembers statements.

2- The statement uses acp:applyProtected. If the agent has write access as a result of the policies specified using acp:access on the ACR where the policy was originally applied then they can remove the acp:applyProtected statement. If the agent has write access as a result of the policies specified using acp:accessProtected on this ACR, then they can add acp:applyProtected statements. The server maintains information on where a policy was originally propagated from i.e. the first resource where a policy was applied using acp:applyMembers.

3- The statement uses acp:applyLocked. If the agent has write access as a result of the policies specified using acp:access on the ACR for the root '/' resource, then they can remove the acp:applyLocked statement. If the agent has write access as a result of the policies specified using acp:accessLocked on this ACR, then they can add acp:applyLocked statements.