43 messages in org.oasis-open.lists.xacmlRe: [xacml] Draft BTG Profile| From | Sent On | Attachments |
|---|---|---|
| David Chadwick | Nov 23, 2010 9:06 am |  .doc |
| Rich.Levinson | Nov 23, 2010 11:01 am | |
| Davis, John M. | Nov 23, 2010 11:48 am | .doc |
| Rich.Levinson | Nov 23, 2010 11:53 am | |
| Smith, Martin | Nov 23, 2010 1:55 pm | |
| Mary McRae | Nov 23, 2010 2:04 pm | |
| Ludwig Seitz | Nov 24, 2010 12:48 am | |
| David Chadwick | Nov 25, 2010 6:13 am | |
| David Chadwick | Nov 25, 2010 6:26 am | |
| David Chadwick | Nov 25, 2010 6:36 am | |
| Ludwig Seitz | Nov 25, 2010 7:05 am | |
| Doron Grinstein | Nov 25, 2010 7:28 am | |
| David Chadwick | Nov 25, 2010 9:05 am | |
| David Chadwick | Nov 25, 2010 9:56 am | |
| Ludwig Seitz | Nov 26, 2010 12:31 am | |
| Ludwig Seitz | Nov 26, 2010 12:53 am | |
| Erik Rissanen | Nov 26, 2010 2:25 am | |
| David Chadwick | Nov 26, 2010 8:51 am | |
| Bill Parducci | Nov 26, 2010 9:06 am | |
| David Chadwick | Nov 26, 2010 9:08 am | |
| Rich.Levinson | Nov 28, 2010 12:41 pm | |
| David Chadwick | Nov 29, 2010 3:45 am | |
| David Chadwick | Nov 29, 2010 4:20 am | |
| Erik Rissanen | Nov 29, 2010 5:38 am | |
| Davis, John M. | Nov 29, 2010 8:45 am | |
| Smith, Martin | Nov 29, 2010 9:59 am | |
| Davis, John M. | Nov 29, 2010 10:41 am | |
| David Chadwick | Nov 29, 2010 11:58 pm | |
| David Chadwick | Nov 30, 2010 12:33 am | |
| David Chadwick | Nov 30, 2010 12:47 am | |
| Smith, Martin | Nov 30, 2010 7:37 am | |
| David Chadwick | Dec 1, 2010 12:34 am | |
| David Chadwick | Dec 1, 2010 12:37 am | |
| David Chadwick | Dec 1, 2010 1:05 am | |
| David Chadwick | Dec 1, 2010 1:28 am | |
| Davis, John M. | Dec 2, 2010 7:37 am | .gif |
| David Chadwick | Dec 3, 2010 1:44 am | |
| Smith, Martin | Dec 3, 2010 5:58 am | |
| David Chadwick | Dec 3, 2010 7:17 am | |
| Davis, John M. | Dec 6, 2010 10:05 am | |
| Davis, John M. | Dec 8, 2010 10:14 pm | .gif, .gif |
| Hal Lockhart | Dec 16, 2010 9:02 am | .gif, .gif |
| David Chadwick | Dec 16, 2010 11:24 am |
| Subject: | Re: [xacml] Draft BTG Profile | |
|---|---|---|
| From: | Ludwig Seitz (lud...@axiomatics.com) | |
| Date: | Nov 25, 2010 7:05:23 am | |
| List: | org.oasis-open.lists.xacml | |
On Thu, 2010-11-25 at 14:36 +0000, David Chadwick wrote:
Hi Ludwig
answers below
...
Hi David,
I have some questions related to the proposed approach:
1.) You propose to introduce a new status code. Why not simply use Advice instead? It seems a bit superfluous to add new elements to the standard when there are suitable elements in the standard already.
the whole purpose of standardising the status code is so that different implementations can interwork without having to find out what the status code or Advice element is that is being set by a particular PDP.
Yes but you can achieve the same effect by just standardizing Advice-ids in a profile, without adding new elements to the XACML-schema and without requiring new behavior.
2.) You propose to introduce a new element called<Consequences>. Why not use either Advice or Obligation with AttributeAssignments instead?
We have used the syntax of Obligations, because this is what they are. But with one difference. They are future obligations that will come into effect if some future event happens. We did not want to call them obligations, since the semantic of these is quote "An operation specified in a policy or policy set that should be performed by the PEP in conjunction with the enforcement of an authorization decision"
Ok I guess then your approach with the "future obligations" is the one I don't see as necessary.
Why not use this procedure:
1. Return an Advice "user can BTG" with the Deny decision 2. Offer the user to perform the BTG action. If the user chooses to do so, a new attribute for that user is created. 3. Resubmit the original request with the new attribute 4. Other policies matching the BTG attribute now permit access (possibly with Obligations requiring special auditing).
General question: From the document you provided I cannot see the necessity for introducing new elements into the standard. Could you try to explain which functionality are you want to achieve that cannot be realized with the existing features of the standard?
1. A standard way of specifying this response type. By its very nature it needs to be in the standard.
2. A standard way of indicating future obligations.
I still don't see the necessity for changing the standard to implement this use-case. In fact Swedish healthcare implements BTG policies using XACML and the approach sketched above. So I'll try to clarify my question:
Given the fact that standardizing BTG in a profile is useful, why can it not be done without introducing new elements/functionality/behavior in the standard?
/Ludwig
-- Ludwig Seitz, PhD | Axiomatics AB Training & Development | Skeppsbron 40 Phone: +46 (0)760 44 22 91 | SE-111 30 Stockholm Mail: lud...@axiomatics.com | Sweden