[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] XACML AzApi as part of F2F agenda
I understand that you want to work though a number of XACML 3.0 work items - though I would humbly suggest that the value of XACML 3.0 would be much enhanced if an AzApi were standardized and available. However, I do note that we made the detailed API submission in July to the TC. Therefore, I dont feel it should be treated at par with various other suggestions that have not yet been fully detailed or even published to the TC. So I would again strongly suggest that the TC find an hour and a half during its three day meeting to discuss this API, before other "future" oriented items are discussed. And, let me give you a small tip as a "standards old-timer". Never discuss the next version (3.1) when finalizing the current one. Its the best way to destroy the value of the work you are doing and confuse the market . If you are not convinced that we are ready for 3.0 (a major release of the standard!), we should simply defer it until we are ready. Thanks, prateek > Hal, > > I agree with you that the existing java APIs are not adequate. We have > done some work on this as well because of that. I think the > "DOM-based" approach, that is defining an API in "pseudo code" if you > allow the term, is the right way to go. And I do think this is an > important topic. I wouldn't be opposed about doing a Java API as well, > but I don't know the IPR/political/etc issues that govern that. > > I also think that a F2F is a good place to start off the work. With my > earlier email, I just meant that priority should be given to finishing > 3.0. I hope, maybe in my dreams, that by the end of day 2 I could post > a new draft which could be promoted to CD and public review at the > call on Thursday morning. This would leave Thursday free for planning > the future. > > So, if there is time after, I think we should discuss the Authz API. > But only if there is time. > > Other post 3.0 topics that I think we could consider if we have time: > > - PEP <-> PDP <-> PIP attribute negotiation and retrieval. > Architecture. Required protocols. Etc > > - Metadata > > - Obligation families > > - 3.1 core (I have some ideas for how to improve a few things in the > core, but they are too controversial for now while we are in feature > freeze) > > Best regards, > Erik > > > > On 2009-12-02 14:33, Harold Lockhart wrote: >> At this point we are simply looking for an agenda item at the F2F to >> discuss a subject which we believe is of great interest to the TC >> members. >> >> The subject of whether the API should be standardized by the TC has >> never been debated. We believe there are sound technical and >> procedural reasons to do so and I would be glad to state them at >> length. However it seems to me that this F2F would not be the right >> place to do so. >> >> I will post another msg describing the reasons that after extensive >> analysis we felt that it was necessary to start afresh rather than >> pile yet another layer on the Java permissions model. >> >> Hal >> >> -----Original Message----- >> *From:* Nataraj Nagaratnam [mailto:natarajn@us.ibm.com] >> *Sent:* Tuesday, December 01, 2009 11:21 PM >> *To:* Anil Saldhana >> *Cc:* xacml@lists.oasis-open.org >> *Subject:* Re: [xacml] XACML AzApi as part of F2F agenda >> >> hi Anil >> >> Yes, I fully understand your perspective. Like you said, >> standardized api is important and i fully support that. Key is to >> make sure developers and all our customers don't have to choose >> between multiple standards in Java APIs but use one that is >> consistent across vendor community. >> >> To your point of lack of APIs - I think one area is (potential) >> lack of full understanding and appreciation of the potential of >> JACC. I know that there is a perception that it is only for J2EE >> containers. While it is targeted for that, in that JSR wg, we >> took efforts to address even callouts from any Java applications >> and alignment with J2Se security model as well. We have seen use >> cases where it is used in non-container environments. >> >> What might have to be done is to identify requirements so as to >> factor that back into JACC instead of inventing another API. Like >> Ron responded in another note, doing this analysis is important >> so that we work towards addressing collective objective around >> standardized apis. >> >> >> Regards, >> Nataraj (raj) Nagaratnam >> >> >> >> >> Inactive hide details for Anil Saldhana ---01/12/2009 >> 11:58:36---Nataraj, While I agree to most of what you said, what >> the TC cAnil Saldhana ---01/12/2009 11:58:36---Nataraj, While I >> agree to most of what you said, what the TC can deliver on is a >> >> >> From: >> Anil Saldhana <Anil.Saldhana@redhat.com> >> >> To: >> xacml@lists.oasis-open.org >> >> Date: >> 01/12/2009 11:58 >> >> Subject: >> Re: [xacml] XACML AzApi as part of F2F agenda >> >> ------------------------------------------------------------------------ >> >> >> >> Nataraj, >> >> While I agree to most of what you said, what the TC can deliver >> on is a >> language independent API similar to what DOM1 did. Java can be >> one of >> the bindings. I was of the feeling that AzApi is along those lines. >> >> Lack of standardized API has been the bane of many of the xacml >> implementors. >> >> Regards, >> Anil >> >> On 11/30/2009 10:28 PM, Nataraj Nagaratnam wrote: >> > Wrt #3 below around Java interfaces -- >> > >> > I am not sure if XACML TC is the right forum to define Java APIs, >> > especially when there are Java standard APIs already available >> and in use. >> > JSR 115/JACC is sufficient in many cases - though it is written >> from >> > container viewpoint, it is equally applicable to any type of >> enforcement >> > points (even if it is apps). If there gaps that should be >> addressed in >> > JACC, I think we should work that in. Those APIs are >> applicable to Java >> > developers who can use it without any knowledge of XACML, or >> other means >> > that a container may even provide. So it provides that level of >> abstraction >> > as well. >> > >> > Regards, >> > Nataraj Nagaratnam >> > >> > >> > >> > >> > >> > >> > From: Prateek Mishra<prateek.mishra@oracle.com> >> > >> > To: XACML TC<xacml@lists.oasis-open.org> >> > >> > Date: 30/11/2009 22:38 >> > >> > Subject: [xacml] XACML AzApi as part of F2F agenda >> > >> > >> > >> > >> > >> > >> > I would like to request discussion of the XACML AzApi during >> the F2F, as >> > we continue to work to advance this towards standard status. >> > >> > The API submission we made this past summer, has a number of >> features >> > would benefit from the TCs review - >> > >> > 1) Use of generics and a highly factored design to allow for new >> > categories and types of attributes. Is this adequate >> > to model the new materials in XACML 3.0 and other XACML use-cases? >> > >> > 2) A concept called "what is allowed" - which supports a >> limited but >> > extremely valuable form of scoped query against >> > access rules. One question is how this can be modeled or >> implemented in >> > the XACML 2.0/3.0 context >> > >> > 3) Based on experience with the open source and our internal >> review of >> > the API, we are planning to submit some additional >> > interfaces to the XACML TC within the next couple of weeks. The >> main >> > purpose of these interfaces is to allow Java developers with little >> > knowledge of XACML >> > to utilize the API. We would like to be able to describe these >> > interfaces in some detail to the TC, together with >> > the rationale for their introduction. >> > >> > I would request the Chairs to allocate an hour and half for these >> > discussions, which would be led by Rich Levinson (he is out >> today - but >> > I thought >> > it important to get this message out to the chairs and TC). >> > >> > Thanks, >> > >> > - prateek >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]