MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xacml] examples in specification
Hi Michiharu. I don't think I got my point across. :) Let me try again.
> I don't agree that the example in section 4.2.4.3 isn't true. The
> obligation described in that rule is "email" with three arguments, an email
> address in the medical record referred by a specific XPath, a text string,
> and subject id in the request context. These three arguments are not for
> PDP but for PEP. PDP does not have to interpret those arguments and the
> whole text string below the obligation element is sent back to PEP as a
> part of the decision. No interpretation by PDP is not required. Instead,
> PEP must understand those parameters but this kind of agreement between PDP
> and PEP is already assumed, as described in section 5.35.
I actually didn't say that the example isn't true. What I said is:
While this isn't illegal, the example implies something about the
specification that isn't true
What I think the example implies (and what I've had others tell me they
see in the example) is that the PDP is supposed to recognize that there
is a Selector or Designator, do the attribute retrieval, and then fill
in the AttributeValue for the AttributeAssignment. Then what the PEP
gets back is the email address as the first parameter, not a Selector
that points to an email address. This is not behavior that is defined in
the specification, but most people I have talked with think that this is
what the example is showing. [1]
This is why I was concerend about this, and other examples. I don't
think that this example is invalid, I just think that it's misleading
people trying to use Obligations. Is that clearer?
seth
[1] I fully understand why this funcationality would be useful, but
that's not the issue I'm trying to raise here.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]