Re: [xacml] saml authz request vs request context (Re: [xacml] Issuesfor the next delegation draft)

[Erik Rissanen <mirty@sics.se>]

Hi Frank,

I don't see how this would break the request context as a functional
interface. The request context is just the interface to the context
handler, where all the attributes have always been "stored", regardless
of their source. But, I don't know the full history or motivations of
XACML, so I don't know for sure. In any case, the external transport
format would maintain full functional characteristics.

Personally, I find it inelegant to have two global contexts in the
description of the processing model, that is, both the "normal" part of
the request context and the extra section in the request context. The
practical reason for not doing this is that it complicates the
definition of the processing model since every place where we refer to a
subject/delegate/etc element in the request context, we also have to
refer to the "additional attributes" section as a source for attribute
matching. Abstracting away the various sources of the attributes and
describing the processing model solely based on the "normal" part of the
request context greatly simplifies the standard.

Anyway, I think we both understand each other's proposals and I doubt
the two of us are going to make any more progress. I suggest that the
issue be discussed at the next meeting for additional input from others.

Regards,
Erik


Frank Siebenlist wrote:

> Hi Erik,
>
> The method that you are describing where the attributes are maintained
> by the context handler is the same as keeping them in some global
> context.
>
> It does not allow you to model the request context as a functional
> interface, which is not very elegant... and diverts from previously
> stated goals (at least I believe it was a noble goal to be able to
> model the xacml evaluation through a functional paradigm (?))
>
> I still haven't heart about any reason not to add the attribute sets
> to the request context.
> Is there any practical reason not to do this?
>
> Thanks, Frank.
>