Re: [xacml] Minutes 31 May TC Meeting

[Anil Saldhana <Anil.Saldhana@redhat.com>]

On 05/31/2012 01:04 PM, Bill Parducci wrote:
> I. Roll Call&  Approve Minutes:
>    Voting Members
>     Hal Lockhart (Chair)
>     Bill Parducci (Co-Chair/Minutes)
>     Rich Levinson
>     Erik Rissanen
>     Remon Sinnema
>     Danny Thorpe
>     John Tolbert
>     Richard Hill
>
>    Members
>     Radu Marian
>     Anil Saldhana
>     David Staggs
>
>    Quorum met (80% per Oasis)
>
> II. Administrivia
>    XACML Core
>     Hal Core PR started 15 day review
>
>    IPC Profile
>     ACTION: Bill will post request for CS and PR with Oasis.
>
>    ITU-T
>     Hal and Radu confirmed Radu is working with Abbie Barbir and that
>     the TC is offering technical support.
>
>    IETF - PLASMA
>     The TC voted to endorse the document posted by John re: IETF PLASMA
>     Tolbert as an official response by the TC.
>     Motion: John
>     Second: Richard Hill
>     APPROVED unanimous consent
>
>    Capturing ToDos
>     Hal reiterated the the wiki is the best place for capturing a
>     variety of input, including links.
>
> III. Issues Active on List
>
>   REST Profile of XACML v3.0
>    Working Version 1,0, draft 04 uploaded. Hal reviewed the current
>    state of the discussion. He opined that by by first focusing on the
>    (more "traditional") PEP/PDP interaction before tackling PAP
>    elements.
>    Remon offered that it is necessary to specify policy management as
>    well so the PAP needs to be addressed as part of the solution.
>    Erik countered that policy management is too complex to address as
>    part of this.
>    Richard concurred, saying that Policy management is beyond the
>    context of the RESTful interface scope specification.
>    Danny suggested that making an update to a Policy requires some level
>    of specification at the PAP level or interoperability may be lost.
>    He is OK with the concept of the declaring that this solution is
>    designed to solve discoverability/performance issues only and that it
>    may be best to address it in this manner at first with the intent of
>    revisiting it when the update (POST) case is better defined.
>    Anil pointed out that the Atom project has recently adopted JSON.
Correction:  Anil pointed out that in his experiences, REST 
architectures typically involve either atom (xml) or json 
representations. So getting a JSON representation of the xacml 
request/response structures would be ideal.

>    Rich suggested tackling the problem in a modular fashion.
>    Hal noted that the first working document the TC is working on is
>    effectively a linear translation of current XML interaction.
>    Danny clarified his position that the Update (POST) mechanism is left
>    undefined at this time.
>    Hal voiced concern that the lack of specification could lead to
>    issues.
>    Danny noted this is left to interpretation for version numbering.
>    Hal suggested that versioning would have to be addressed via the
>    structural definition of the specification.
>    Remon suggested that if we split the PDP and PAP profiles it would
>    lead to significant overlap in the Profiles.
>    There is general consensus that if the PAP interaction is not fully
>    ready at this time it would best to remove if from the discussion
>    rather than create two separate Profiles.
>
>
>    JSON Representation in XACML
>     Hal raised the question if the TC wants to create a representation
>     that is good enough for Polices and request/response in "Phase 1".
>     "Phase 2" would entail developing a "round-tripping" mechanism
>      between XML and JSON.
>     "Phase 3" would involve a comprehensive JSON based solution;
>
>     Anil opined that if we can represent request/response in JSON it
>     would address most Use Cases. Hal noted that there seems to be
>     significant interested in seeing Polices and "round tripping".
>     Danny agreed, saying that a mechanical solution to perform mapping
>     will be necessary, since JSON is not suited for human consumption.
>     Hal voiced a concern that the TC ensure that the JSON solution
>     implemented for the request/response mechanism is applicable to Policy
>     notation.
>     Danny suggested that if the TC is concerned about selecting the
>     "wrong" JSON/XML mapping standard that we it consider developing it's
>     own mapping.
>
>    Comments posted on XACML-Comments
>     Hal noted that there were some comments posted pertaining to XACML
>     Core specification. He encourages the TC to take a look at the list
>     to evaluate those recently posted.
>
> meeting adjourned
>
> b