OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xacml] Minutes 31 May TC Meeting

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

    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.

    Hal and Radu confirmed Radu is working with Abbie Barbir and that
    the TC is offering technical support.

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]