[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]