OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml] Proposed Agenda for 28 June TC Meeting


Erik,

On feedback 1,  then policy-id (identifier of a policy) will be clearer than policy-label (human-readable indication of a policy). So for example, such resource attribute designator would then be expressed as:

<AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
   AttributeId="urn:oasis:names:tc:xacml:3.0:resource:policy-id"
   MustBePresent="false"
   DataType="http://www.w3.org/2001/XMLSchema#anyURI"/>

On feedback 2, what I am proposing is a single policy-template with multiple policy-template-parameters (your first interpretation) rather than a single policy with multiple conditions. Imagine that the number of possible instances (i.e. final, parameterized, policies) can be very large, which is exactly the case in the TAA example. It is far more workable to distribute to a large number of organizations one single TAA policy-template, and then distribute to a large number of organizations the few number of policy-template-parameters that would be needed (by the tools as you said) to locally construct the actual policies.

I agree with you that there is no change required at run time. The proposal then is not to change anything to XACML 3.0, but to propose a profile for policy templates, that would define:
a) How XACML 3.0 can be used to express policy templates
b) How XACML 3.0 can be used to express policy templates parameters
c) The workflow that tools would follow so policy templates and policy templates parameters can be combined to produce actual policy template instances

Attached is a revised version of the feedback with examples, that hopefully help clarify the proposal.

Policy template = example 3
Policy template parameter 1 = example 4
Policy template parameter 2 = example 5

Tool would produce the actual policy template instance (example 1) by combining policy template (example 3) with policy template parameter (example 4)

I hope that this makes sense. Now I heard someone saying, during the last meeting, that some of this parameterization could be achieved using existing constructs. Do you know what this referred to?

Jean-Paul Buu-Sao



-----Original Message-----
From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Erik Rissanen
Sent: Thursday, June 28, 2012 07:23
To: xacml@lists.oasis-open.org
Subject: Re: [xacml] Proposed Agenda for 28 June TC Meeting

Jean-Paul,

My comments are below.

Regarding policy binding by reference, this can be easily achieved with the current functionality, like you explain yourself, but I don't think it is necessary to define a new attribute category. Defining a resource attribute would be enough. Something like:

urn:oasis:names:tc:xacml:3.0:resource:policy-label

The policy/PDP can then use this to select the applicable policy among many, just by the normal XACML mechanisms (or some optimized behavior in a particular environment if needed).

Regarding parametrized policies, maybe I don't understand it correctly, but I can interpret it in two ways.

The first is to see them as policy templates. In that case, I think it is a matter of tooling to fill in the templates in the system at the appropriate time, not that we need to modify the standard.

My other interpretation is that you want the same policy to behave differently depending on some data in the request. In that case you should simply use a condition rather than a target, since then you can "fill in the template" by passing in attributes in the request. With a condition you can match two attributes against each other, not just one attribute against a constant value.

Best regards,
Erik




On 2012-06-28 07:02, Jean-Paul Buu-Sao wrote:
> Bill,
>
> Per the minutes I expected that we would also discuss the Feedback from TSCP on XACML 3.0 Public review 04? In particular it was mentioned that the parameterized policies, that TSCP is calling for could be partially achieved using e.g. VariableDefinition?
>
> Thanks,
> Jean-Paul Buu-Sao
>
> -----Original Message-----
> From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] 
> On Behalf Of Bill Parducci
> Sent: Thursday, June 28, 2012 03:07
> To: XACML TC
> Subject: [xacml] Proposed Agenda for 28 June TC Meeting
>
> Time: 13:00 EDT (GMT-0400)
> Tel: 513-241-0892
> Access Code: 65998
>
> Proposed Agenda for 28 June 20112 TC Meeting:
>
> I  Roll Call & Minutes
>
>    Approve Minutes:
>     14 June 2012 TC Meeting
>     https://lists.oasis-open.org/archives/xacml/201206/msg00030.html
>
> II. Administrivia
>
>    XACML v3 Combining Algorithm uploaded
>     https://lists.oasis-open.org/archives/xacml/201206/msg00031.html
>
>    XACML TC Summary Overview
>     https://lists.oasis-open.org/archives/xacml/201206/msg00032.html
>
>    XACML Interop demo opportunities
>     https://lists.oasis-open.org/archives/xacml/201206/msg00034.html
>
>    Status XACML IPC v1.0 Profile
>
> III. Issues
>
>    Proposed PAP Architecture
>     https://lists.oasis-open.org/archives/xacml/201206/msg00026.html
>     (continuation of thread)
>
>    JSON Mapping
>     https://lists.oasis-open.org/archives/xacml/201206/msg00024.html
>
>    Metadata Profile inquiry
>     https://lists.oasis-open.org/archives/xacml/201206/msg00011.html
>
>    REST Profile API/PolicyId/General Plan
>     (no recent postings)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-help@lists.oasis-open.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-help@lists.oasis-open.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-help@lists.oasis-open.org

Attachment: 20120628_Feedback on XACML 3.pdf
Description: 20120628_Feedback on XACML 3.pdf



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]