OASIS eXtensible Access Control Markup Language (XACML) TC

  • 1.  Groups - XACML/RSA 2008 InterOp Conference Calls added

    Posted 11-30-2007 14:18
      |   view attached

    Attachment(s)

    ics
    ical_17104.ics   18 KB 1 version


  • 2.  Groups - XACML/RSA 2008 InterOp Conference Call TOMORROW - REMINDER!

    Posted 12-05-2007 22:37
    I will not be on the call but Jane will be.
    Thanks,
    Dee




  • 3.  Groups - XACML/RSA 2008 InterOp Conference Call TOMORROW - REMINDER!

    Posted 12-05-2007 22:37
    I will not be on the call but Jane will be.
    Thanks,
    Dee




  • 4.  Groups - XACML/RSA 2008 InterOp Conference Call TOMORROW - REMINDER!

    Posted 12-05-2007 22:38
    I will not be on the call but Jane will be.
    Thanks,
    Dee
    
    


  • 5.  Re: [xacml-demo-tech] Groups - XACML/RSA 2008 InterOp Conference Call TOMORROW - REMINDER!

    Posted 12-06-2007 16:15
    As discussed at today's conf call: ref to Burton Catalyst interop doc:


    http://www.oasis-open.org/committees/download.php/24475/xacml-2.0-core-interop-draft-12-04.doc

    Thanks,
    Rich

    Dee Schur wrote:
    > I will not be on the call but Jane will be.
    > Thanks,
    > Dee
    >
    >


  • 6.  Re: [xacml-demo-tech] Groups - XACML/RSA 2008 InterOp ConferenceCall TOMORROW - REMINDER!

    Posted 12-06-2007 16:16
    As discussed at today's conf call: ref to Burton Catalyst interop doc:
    
        
    http://www.oasis-open.org/committees/download.php/24475/xacml-2.0-core-interop-draft-12-04.doc
    
      Thanks,
      Rich
    
    Dee Schur wrote:
    > I will not be on the call but Jane will be.
    > Thanks,
    > Dee
    >
    > 


  • 7.  Re: [xacml-demo-tech] Groups - XACML/RSA 2008 InterOp Conference Call TOMORROW - REMINDER!

    Posted 12-06-2007 17:14
    Hello prospective RSA Interop participants, esp callers of today's conf
    call,

    Also attached are the 2 documents associated with the emails copied below.
    I am also attaching a glossary I dug up thru one of the links ref'd in the
    emails below, which I found useful while looking thru the Use Case
    Models.pdf
    document. Finally, I also dug up this link, which gives an example of one
    of these health care records that is discussed in the use cases doc:


    http://www.infoway-inforoute.ca/en/img/work/AnimatedEHRwithCallouts_DH3.gif

    Presumably, if we follow the Burton Catalyst Interop approach, we would need
    some kind of sample appl that everyone could use that showed something
    like the
    above link. But, based on the scenario description in the 1 page doc,
    what we
    really need is the appl/xacml-client to interpret the xacml return data,
    presumably
    some Obligations with vocabulary indicating the privacy directives that
    the appl
    must enforce wrt to what data can actually be shown to the caller, which may
    also involve a lookup on whether patient has any consent directives that
    pertain.

    Based on my reading, the Use Case Models.pdf doc is primarily a mgmt
    system for
    the patient data, in particular, for the patient's decisions about how
    their data must
    be handled by the health care provider (as opposed to actual personal or
    medical
    info about the patient - i.e. the doc talks about scenarios for managing
    the patient
    "metadata"). In any event, the point I am trying to make is that the
    scenarios we
    are probably going to implement are NOT the ones in the Use Case Models.pdf
    doc, but the ones in the one page description which is about actors
    accessing
    data that is controlled by the types of privacy preferences and consent
    directives
    that had been put in place by the Use Case Models.pdf application.

    To dig myself even a little deeper on this, my inference is that the
    scenarios
    in the Use Case Models.pdf doc actually "result in" a set of XACML Policys
    being created. Our focus will be to create policies similar to what such an
    appl might create, but not write such an appl ourselves in anyway, except
    possibly if we want to do the Policy Exchange type use case to see if
    vendors
    can create interoperable policies of this nature.

    What the main focus of the Interop should probably be, imo, is that given
    a set of XACML Policys that we create, we will then have clients access
    the test appl, which will have a xacml-client, which will make a request
    that activates the aforementioned policies, and recieves a result which
    will tell the appl/xacml-client what can and cannot be done wrt to the
    request.

    The key work that I see in doing the core part of the scenario is:

    1. defining the XACML Policys that will be used.
    2. defining how the XACML Policys return the directives the
    xacml-client must comply with

    My assumption and hope is that we will build around the XACML Obligations,
    groundwork of which was already laid in the Burton Interop by returning
    "display" Obligations and "approval" Obligations and focus on defining a
    vocabulary for these Obligations that will allow for clean appl/xacml-client
    interoperability.

    Comments and suggestions welcome. The above is primarily intended to get
    discussion
    going on the details of what would seem to be the critical path to get
    some scenarios
    operable with minimal investment of resources starting from where the
    previous
    Interop left off.

    Thanks,
    Rich



    *Message 1 re: the 1 page Interop overview proposal:*




  • 8.  Re: [xacml-demo-tech] Groups - XACML/RSA 2008 InterOp ConferenceCall TOMORROW - REMINDER!

    Posted 12-06-2007 17:17