MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xacml] #31: Passing arbitrary sets of Attributes in the request(Re: [xacml] Minutes of 27 April 2006 XACML TC Meeting)
The description of the processing model would be more complex since it
has to refer to two distinct ways to find attributes. First, through the
Delegate section of the current request context, and second, through
this new proposed special section in the request context. I just don't
see why it necessary to treat attributes passed with the request
differently from other attributes. We don't have a special section in
the request for attributes found in a directory, another section for
attributes provided by the PDP (for instance time of day), another
section for attributes loaded from a file on disk, etc.
Specifically section 7.2.5 of the standard would have to be made more
complex. If we do not modify the request context, then there are no
needed changes.
Yes, I agree that you end up with the equivalent processing in either
case, but the difference is in that the standard and the XACML schema
will be cleaner if we do not introduce special constructs.
Yes, an implementation would need to have a special structure with a
pointer to the attributes provided while it evaluates a request, but
this is the case in any way, since no PDP implementation would work with
the XML form of request context. It's all internal data structures by
that stage. This state is not global. It is per request.
The PDP will still be "functional" if you don't implement any other ways
to find attributes besides the attributes provided in the SAML request.
There is one benefit with Frank's approach. It is that if there are
multiple interfaces for invoking a PDP, say the SAML profile and then
maybe also a WS-*-profile, then having this functionality in the xacml
schema, then both of these interfaces could potentially inherit the new
functionality.
Personally, I think the benefit of a cleaner processing model is bigger.
Anyway, this is my opinion, and I can live either way. :-) I suggest
that the TC should make an informed decision on this issue so we can put
it at rest. We have been discussing it since the Ottawa F2F now. Perhaps
it would be good if you Frank join the discussion on the phone with us?
What do you see as the big benefits of changing the Request context?
Regards, Erik
Frank Siebenlist wrote:
>#31: Passing arbitrary sets of Attributes in the request
> (for use with subsequent potential delegates). Erik
> thinks it would just make the request and its evaluation
> more complex; would need a way to refer to these
> "potential attributes". Are the Attributes "invisible"
> until the associated delegate appears in the reduction?
> Erik proposes passing such Attributes would be outside
> the core specification. Implementation-specific Context
> Handler is responsible for making these available when
> appropriate. Erik thinks these should be added to the
> SAML Profile. Alternative would be putting them in the
> XACML Request. Profile would provide way to pass
> Attributes in XACML Attribute format, so they don't have
> to be converted back to SAML Attributes. Profile will
> also need an ID element structure so Context Handler can
> tell which identity various Attributes are associated
> with.
>
>
>Could Erik maybe elaborate on the issues raised?
>
>I do not understand arguments that passing the attribute sets in the
>request context makes the evaluation more complex.
>What is the alternative? Wouldn't you always end-up with the equivalent
>processing no matter how you pass them?
>
>If you do not pass them in a "functional" argument, then you have to
>rely on global state to pass those attribute sets, which is most of the
>time undesirable.
>
>We have the equivalent working in our Globus Toolkit authorization
>Java-code for some time now...
>
>Regards, Frank.
>
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]