clarifications/questions for worklist items 26, 29 and 32

[Frank Siebenlist <franks@mcs.anl.gov>]

TC members,

I looked through the review and added some comments and clarifications.

Anne Anderson wrote:
> ...
> 26. Define policy reduction (partial evaluation) of a policy
> 
>   This was assigned to Frank as a Grid requirement, but at the
>   SAML F2F, the working group determined there were existing ways
>   to meet the Grid requirement.
> 
>   This is a candidate for closure unless someone wants to pick it
>   up as useful for policy analysis, debugging, etc.
> 
>   Any takers?  If not, this should not be on the agenda for the
>   F2F.
> 
>   F2F: probably not.

The application that I see for this is that scheduler use case, where such a 
scheduler has a need to combine and possibly reduce the requester and potential 
service provider policies, and use that combined policy to determine if 
potential scenarios are allowed. It is somewhat like wspl policy reduction, but 
the scheduler may want to use a normal authorization query interface on the 
combined policy to check for permission.

I can't really remember anymore what we decided at the SAML F2F about this...


> ...
> 29. Policy Authority Delegation
> 
>   We had a number of questions about this.  It needs
>   clarification.  Issues:
> 
>   a. Define "domain".  What does it correspond to?
>   b. Could this be solved using a subject-domain or
>      resource-domain attribute that the PEP should include in its
>      Request, and that policies could match on?
> 
>   Wait for Frank to provide clarification before putting on F2F
>   agenda.
> 
>   F2F: not until/unless Frank clarifies, but then possibly

I have the feeling that all the "delegation" related items will be solved when 
we tackle the "right of a subject to administer policy for a certain target".

I reworded the description in item#29:

29. Policy Authority Delegation

    The ability to express in a policy rule that a certain authorization 
authority is allowed to administer access control policy for a certain target.
The evaluation for a certain target should probably yield "Indeterminate" or 
"Not Applicable" (?) according to the local policy, it should yield "Permit" for 
the right of an authorization authority to administer the policy for that 
target, and either the authorization query to that authorization authority's PDP 
should yield "Permit" or the evaluation of the pushed access control assertion 
by that authorization authority should yield "Permit".
If the local policy yield either "Permit" or "Deny", the foreign authorization 
authority doesn't have to be considered.(?)

    TYPE: New functionality
    STATUS: potential work item.  Related item#1.
    PROPOSAL: #1 in:
     http://lists.oasis-open.org/archives/xacml/200308/msg00008.html
    CHAMPION: Frank Siebenlist



> ...
> 31. Attribute Issuer as Subject
> 
>   The attendees had a number of issues with this and feel the
>   work item needs a more precise definition.
> 
>   a. Can this be solved using an XACML policy used by the PDP's
>      context handler: Something like 'subject A is allowed to
>      perform the "issue" certificate action on resource "subject
>      B" or resources with attribute "name-domain" = B'
>   b. Is this mainly an issue of aligning SAML and XACML syntax?
>   c. Does an authentication chain really belong in the resource
>      policy?  Isn't it a separate policy?
> 
>   F2F: not unless clarified, then possibly


Need some more time to think about that one...


> 32. Standardize naming to specify rules for requestor's authz policy
> 
>   Again, clarification is needed.
> 
>   a. What entity is the "requestor"?  The PEP?  We don't usually
>      think of a "requestor" having its own policy...
>   b. Would this perhaps be a Grid Profile for Use of XACML?
>   c. XACML already allows new SubjectCategory values to be
>      defined simply by defining a new urn.  Grid could define
>      such a urn.
> 
>   F2F: not unless clarified, then possibly

This issue is not grid specific.
I understand the confusion around the naming.
Let me rewrite the item as follows:

32. Standardize naming to specify rules for requestor's authz policy

    In a setting where a requester invokes certain operations of a service 
provider, the convention for the target of the service provider's policy  is 
well defined: subject=requester, resource=service-provider, and action=operation.
However, when we consider the policy evaluation on the requester's side to check 
whether an invocation on the service provider is allowed according to the 
requester's policy, then is it less clear.
It is almost a mirror case, but if we take a convention where the "resource" is 
the one protected by the policy, the we should equate subject=service-provider 
and resource=requester with the same action=operation.
Unfortunately, if we also have to consider the possibility that the 
service-provider can invoke an equivalent operation on the requester, then we 
need an additional way to discriminate between these cases.
Maybe we can label the action with a category of "out-bound" (?).

    TYPE: New functionality
    STATUS: potential work item.  Related item#1
    PROPOSAL: #4 in
     http://lists.oasis-open.org/archives/xacml/200308/msg00008.html
    CHAMPION: Frank Siebenlist


> ..

That's it for now.

-Frank.

-- 
Frank Siebenlist               franks@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory