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:
343b5bd6-9d93-434e-a76e-9912f9fbc649@default" type="cite">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
Anil 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
