MHonArc v2.5.2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [xacml] Attesting implementations and <type>-map,Match arg order issues
On Mon, Dec 02, 2002 at 03:48:39PM -0500, Polar Humenn wrote:
> It took me a while to grasp your implementation, but I think the
> difference between your system and ours, is that we use a "unifying"
> typechecker.
Actually, I think our implementations aren't so different, but I also won't
bore people with the details now. (I probably just didn't explain our
approach quite right)
> It seems that you "lookup" a function named in the Apply construct and
> then ask the function for its return type and then you know what return
> type the <Apply> node has, correct? The map function complicates this, by
> you having to look up the next argument and ask it. However, it looks like
> you forgo this approach for a runtime type check, which is fine.
Yes, we do this "lookup" but we don't have any runtime checking needed to
support it. As I said in my previous email, the map function only complicates
this from the API point of view, since it may require programmers to do a
little more work.
> We've completely eliminated run-time checks from our evaluation engine. We
> convert every XACML condition into a tree of Expression nodes that are
> evaluated against a context and environment. Any new function introduced
> to XACML follows the same API any other function does. "Map" and all the
> other highter order functions use the same exact API as any other
> function. Therefore, our internal API is the extension API as well.
Actually, that's basically what's going on in our system too. It's too
hard to describe the subtle differences succinctly, so I won't try here.
When I get more time on my hands I'll send you a better reply.
seth
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC