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