W3C Workshop on Access Control Application Scenarios -- 18 Nov 2009

<rigo> scribe: tlr

<rigo> scribenick: tlr

Hal Lockhart, The State Of Access Control 2009

-> http://www.w3.org/2009/policy-ws/papers/Lockhart.pdf paper

DC: If you don't know where the attributes come form, you don't know whether you can trust them.
... these statements come from "this party can issue this attribute"

HL: that information exists, it is outside of XACML

DC: you said the SecPAL approach wasn't feasible, and I'm disputing that.

DN: security and privacy of attributes -- is this about certifying attributes?

HL: CARML language
... look at IGF project on openliberty
... briefly, idea is instead of specifying on low level "go to this dir, take this attribute" lets you make higher level statements what attributes are used for
... what properties are etc

RW: What kind of comments did you get for the privacy profile?

HL: That profile is extremely minimal -- just defines purpose attribute
... developed in 2.0 time frame
... looked at EPAL, and that looked like it was the only thing we needed to add
... various references to core spec

PS: purpose is for access control, not privacy
... restricting access based on purpose is access control, not privacy

RW: depends

TR: It is access control motivated by privacy

HL: healthcare scenarios
... presentation yesterday was very similar to XSBA (?) demos
... healthcare profile generated based on @character salad@
... dealing with things like emergency, etc etc
... on purpose -- often people say "not sure what people do in the future"
... but in the case of healthcare, often using specific systems
... so turns out not to be an issue

PS: emergency -- different policy?

HL: yes, attribute "emergency has been declared"
... more logging, less checking

GN: purpose is attached to resource as resource attribute -- for which purpose can the resource be accessed
... shouldn't this be part of the policy?

HL: think the semantic is that it's the purpose for which the data is collected
... the logic you're talking about is in the policy

GN: there's a purpose attribute associated with the resource, and one in the request; the one in the request needs to be in the list of purposes for the resource

HL: good comment
... side remark: the work we do is public immediately
... also, public comments
... -dev list for developers
... for XACML, separate list xacml-users which is supposed to be about issues related to design of policies

RW: interested in timing

HL: trying to close the box on 3.0
... expect selective implementation of profiles instead of giant switch-over

FSP: how difficult is it to get a profile accepted?

HL: except for timing -- easy
... in particular when you actually work on it
... "here's a document, I'm going to edit it" is a good way to get things done

RW: privacy attributes, privacy profile -- how to contribute?

HL: note only the core defines a schema -- administrative stuff uses new elements, those are defined in the core

GN: profiles only come out if new version?

HL: no, XSPA is on its own schedule
... but some of these things have dependency
... if doesn't impact other things, can move through -- more confusion in marketplace, but deal with

FSP: what about profiles that just use extension points?

HL: no single statement
... profiles have independent conformance points
... most require conformance with core as a precondition
... could use the definitions in export control with whole new policy language
... no one definition -- profiles can extend, narrow, ...

PS: a bit more what you're looking at for multi and hierarchical

HL: the answer would be long
... a lot of the comments and the changes proposed came from OGC work
... in addition to doing geospatial stuff, OGC were the first to using XACML in web services environment, srsly

Bottom-Up approach for Compliance: The MASTER position (Emmanuel Pigout, Philip Miseldine, SAP Research)

-> http://www.w3.org/2009/policy-ws/papers/Pigout.pdf paper

-> http://www.w3.org/2009/policy-ws/slides/Pigout.pdf slides

ME: what kind of standardization do you envision?

EP: looking at OASIS as appropriate body
... not really an ontology; looking at OWL-S, WSMO
... some work done at the WSDL level to add semantics

GN: what is it you want to standardize?

EP: would like to standardize evidence model
... how you represent evidence

NP: using PSL formulas to express these
... quantify what a particular service provides and do direct comparison?
... or have standard shapes of formulas?
... how do you benefit from using PSL form?

EP: policy -> PSL through BPEL annotations
... advantage of PSL is that in MASTER, at design time doing pi calculus, can do formal verification
... able to verify
... PSL can be translated

NP: Do you know work by Maike Gilliot (sp?)?

EP: MASTER works together with TAS3 and PrimeLIfe
... compliance -- glue between trust, privacy etc

<accorsi> Maike Gilliot <http://www.informatik.uni-freiburg.de/~accorsi/papers/PL_e-abstract.pdf>

EP: ultimate purpose is to show that business is under control

coffee

Towards Standardization of Distributed Access Control

<caribou> paper

<rigo> scribe: rigo

<scribe> scribenick: rigo

you will lose obligations

ML: aggregation also supresses ??
... combination of various attributes, we don't do, we only do aggregation on one attribute, remains linear, check for circular refs

DC: if refer and refer, how would you know

ML: we do a depth search first

NP: do you compare on synatx or on something?

HL: just compare decisions

ML: and send them around PDPs

ME: model you're applying, is it true that root on top takes the decision for all the subnotes?

ML: basically yes, but we can also combine and decide on a lower level

HL: you're using the known policy evaluation mechanism
... multiple PDP discussed a while ago, wasn't taken any further, standards people are reluctant to take complexity on where there is no clear need..
... I don't know how you approach distribution

ML: the PIP is querying

HL: don't want to specify distribution in the policy, you want to do that separately

ML: consider different users are querying, first operator is different for each user
... that's why we made it dynamic

HL: doing runtime resolution

ML: yes

MK: ??

ML: Secpal has no negative negations,

MK: datalog?

ML: we are purely based on XACML, negation solved by grant/deny

MK: what do you use for verification for privacy?

ML: as difficult as for the standard

<dsr> (secpal has open world assumption)

Towards Modelling and Verifying Dynamic Access Control Policies for Web-based Collaborative Systems

HL: question is if you always end up with the concrete model or whether you get abstraction

MK: in many cases there are abstractions

ME: example policy, how can the formal system find out the weaknesses without knowing the security goals

MK: you should know the spec of your systems
... many more complicated sytems. In more complex systems, you still are complex, but you can get some abstraction. At some point you can export from this to XACML

AM: it is possible to model XACML, problem is to find out how to prevent attack. if there is no relation between paper and eve. Now if charly comes on, if eve has already relation to paper p, deny. Can model this with XACML.

DC: issue, if you write a policy and you don't yet about the issue, you can't say

MK: there are other steps they don't know and the formal model helps to discover
... may be only considered one way, there more

RA: finding ways for violation, so no policy specification

MK: can verify in the verification language

HL: properties: nobody can review their own paper...
... state the properties you are stating

DC: if you haven
... t tought about the attack, you won't get to it

HL: someone ran a model against our model, has that hole because of that property and I said, you just assume it has that property

NP: tool has own language?

MK: yes

ML: what is the key diff between datalog or secpal

MK: we don't use secpal or datalog, because doesn't work with our model

ML: advantage of X-Policy

MK: policy is expressive in web scenarios, in verification part, we check it with a model
... cannot implement with standard model checkers

LB: what doesn't work with Secpal

MK: some tokens are permitted or denied, we change state dynamically, secpal is stateless

ML: you make evaluation at each request?

MK: each request changes the state of the system, looking for credential in different states

ML: requested subreviewing is a state?

LB: with Secpal you can specifiy duty, verification of properties is out of scope

DC: we have stateful PDP, records state. It is possible to build it

HL: does it scale

DC: well.....

HL: general problem with duties and large scale systems

discussion

================================

HL: standardization is not a goal in itself, if there
... define extension in the schema but profile the implementation
... bottom up place, charter constraint is on access control, as long as it is consistent with work
... I have concerns about attributes, that's where people are blocked, instead of all people around solving only for themselves
... so much done in the past, we should explore that
... specs are built with extension points, so that company, some industry branches can use them
... how many people do implement? Only if it is sufficiently broad, should go to TC, but we are not gatekeepers
... OGC is done in OGC is good example

TCB: different policy languages for spec.. All of these languages

DC: this is where I want XACML to losen up. Wire Protocol is key. allows you to do many things. One standard request response context, we can merge many of that

HL: yesterday provision of dynamic policies, generalization would be easy

DC: extension would be policy-type
... just element-any as a choice

HL: imagine people could agree on that as it is such low impact
... so many customers don't do schema-checking, too much cost
... if you could make that suggestion to comment list

AM: wire prot. good, in OGC, when you pass in auth decision request, it contains many position descriptions, big number of points. You're blowing up the request
... people were asking to put this in policy instead and instruct PDP to go get the data over there

HL: don't get confused with packaging/implementation and model. Any implementation will have the possibility to go fetching, but it is not efficient
... I have lots of environments that need high performance, so remote PDP wouldn't work
... so just come into TC and push for your solution
... things happen because there are champions
... for 3.0 you can have policies about policies. creating dynamic policies, evaluated only in the context of that request
... when we define the schema, has to be XACML policy, DC wants any policy

AM: want where the attribute can be fetched

HL: question is where you want to attach it, outside the policy

AM: outside the PDP, only selctor and designator, if in the request context we would have URI
... PDP would go and get..

HL: if selector and fetch group attribute, in discover that you need to get that from elsewhere, than go get it, but not in the policy

AM: how to fetch is in the request context

DC: PIP lift context. We have a paper on it.

HL: References instead of values

RW: this is what the SW is about

AM: different context

HL: URI is a supported data type

AM: you have to define what it means

DC: environment attribute, then pass on URI

AM: you need to know what it is, so you have to specify in the request
... has 3.0 covered everything?

DC: we coverd in a way that it is conformant, but there is no standard way of doing

<scribe> ...done that in OGF

UNKNOWN_SPEAKER: GFD 157 GFD 159 as specifications from OGF

HL: most common argument I hear that XACML is too complicated, now I hear not complex enough?

RW: fetch attributes

AM: put references where to fetch

HL: whether you sent request or information in the request

AM: mobile client, mobile client needs to get context, that would explode mobile device,
... ref would allow you to discover that you're still in same request context, could be localhost
... attribute ref, URI, than PDP does it

HL: server has PDP and PIP and PIP is fetching

TCB: the URI should not be localhost

RW: how to connect SW

HL: PDP type information

ML: only thing you want to have is a comparison thing

<carrasco> Something taking into account http://www.w3.org/DesignIssues/LinkedData.html

ML: otherwise you only want to have a name attribute value pair

HL: function go over to this guy who understands... hasn't been explored so far
... XACML doesn't know anything about it, it's about strings as long as

Anna: XML doesn't allow to express relationships
... if the subject would be expressed in RDF, the relations could also be protected

DSR: relationship is just a resource

HL: could treat as resource, you have actions on it

GN: Relation in a social network is different from RDF relations

HL: you can model that as actions on resources, change persitent state on resources

=============================

<caribou> scribe: carine

<caribou> scribenick: caribou

Extending XACML for Open Web-based Scenarios, Pierangela Samarati

-> http://www.w3.org/2009/policy-ws/papers/Samarati.pdf paper

RW: is propagation of AC part of your scope?

DC: OAuth?

PS: we will discuss this

<dsr> Perhaps it would be better for the policy to separate the condition e.g. age > 18 from the accepted means to prove that

<carrasco> Photos http://sn.im/xacml

<dsr> this would allow the user agent to determine which means would minimize disclosure of personal data

<rigo> PS: fancy negotiation doesn't work, need user interaction and reasoning and abstractions

HL: your 4 goals are independent from each other?

PS: abstractions and recursive reasoning are very much related to each other

RW: if you use ontologies you can use SPARQL for reasoning

PS: it's time to have a way to communicate the policy to the user

RW: there's a // activity at MIT called PAW (Policy-Aware Web)

PS: either you request the client to present everything, or you ask only if you don't find something
... closed-world assumption is if you don't have my age you deny access
... you should have to way to ask

DC: just present a bunch of referrals instead of attributes
... you have to trust the system not to pick too much

PS: a user proxy, e.g. wallet full of certificates?

DC: no, just present available referrals

PS: then you need to tell a proxy all the referrals, and associated policies

DC: all my attributes are asserted by 3rd parties
... I only give the list of third parties you can get the attributes from

PS: I should not even be disclosing that I have attributes

DSR: the user wants to know why the service is asking the information
... if I give a list of what I could provide, it's much more than needed

GN: reasons for not storing at the server
... you have to go back to the user

DC: pull-model is an alternative

<rigo> PS: but the issue here is support for the server not to reveal everything to the user

<rigo> ...need dialog for this

DC: in the pull-model, the conditions are not revealed to the user

[debate over privacy of the user vs. privacy of the server]

Obligation standardization, David Chadwick

-> http://www.w3.org/2009/policy-ws/papers/Chadwick.pdf paper

DC: [describing what's missing in XACML]

-> http://www.w3.org/2009/policy-ws/slides/Chadwick.pdf slides

HL: I would like to see a list of obligations
... the PDP does not agree, it's just doing predefined processing
... we don't have a model for the subject in the AC model

ML: the PDP is not doing semantic specific things
... just checking
... 5 types of relations between obligations = unrelated, conflict, contradiction, inclusion, subordinated

RW: sorry for repeating. in P3P, caching, ordered statements
... even if it was simple to read, the ordered thing confused people

ML: in the policy itself you have relations?
... obligations are ordered in execution order?

RW: it does not have obligations

ML: we specify relations because we can't specify order
... but we can easily describe the relations (thx to a unique ID)

[HL showing a slide "obligation families"]

RW: work on obligations in PRIMCluster
... Feed that to the XACML TC

HL: XACML TC has a history of submitted material

HL will send a pointer to this, Rigo to relay to PRIMCluster

=== coffee break ===

<dsr> see http://wiki.oasis-open.org/xacml/ProposalForObligations

<dsr> obligation family draft

<dsr> http://www.oasis-open.org/committees/download.php/27230/xacml-3.0-obligation-v1-wd-03.zip

<dsr> we resume after the break

<dsr> scribe: dsr

Credential-Based Access Control Extensions to XACML, (slides) Jan Camenisch, Sebastian Mődersheim, Gregory Neven, Franz-Stefan Preiss, and Dieter Sommer, IBM Research – Zurich, Switzerland

slides: http://www.w3.org/2009/policy-ws/slides/Neven%20credential-based.pdf

GN steps up to the podium to give the first of 2 talks

<caribou> Scribe: dsr

GN: we want to move away from disclosing your identity to proving selected attributes as needed for the task in hand

HL: XACML has been that way from the start

GN: a concert ticket can be considered as a kind of credential

HL: there is a large literature on this that refers to that as a capability

DC: you probably mean trusted LDAP rather than LDAP since there is no trust model for data retrieved from a vanilla LDAP server

GN: yes
... one question for different solutiions is whether attributes are dynamic or static, and can they be authenticated

(see slide 9)

GN: reference to an attribute as {id, issuer} may not be sufficient, you also want to know the credential type involved

DC: you could cover this in an ontology that defines abstract types

HL: you can define an attribute type as {id, issue, credential} if you want

GN: sometimes it is critical that several attributes are from the same credential, e.g. credit card and expiry date

DC: better example first name and last name

GN: say you want to establish that your name is the same on two credentials but not to disclose your name

GN shows example policy (slide 11)

GN proposes use of SAML to carry conditions on attributes and provisional actions

This is to convey this information to a user agent (a client)

HL: any kind of credential has to be bound to the issuer, and a request/session

One of the issue features is called "holder of key"

HL and GN to take the details offline

GN: SAML needs extension to support any kind of proof token and not be restricted to XML signature

(DSR agrees with GN that authetication shouldn't be part of the access control directly, and should be instead associated metadata)

TCB: What is the difference from X.509?

GN: we add a treatment of privacy
... we are proposing a generalization of existing technologies for use in access control
... X.509 is a special case of credential

PrimeLife Policy Language

slides: http://www.w3.org/2009/policy-ws/slides/Neven%20PrimeLife.pdf

GN introduces scenario of data subject communicating with data controller (slide 2)

Slide 3 introduces role of XACML for policies and SAML for conveying info

Sticky policy is a agreement on what data controller may do and must do in relation to data subject's personal data

Slide 8 summarises authorizations and access control. Note role of downstream access control

<caribou> "aliens landing on earth" ?

an example of predefined trigger...

AM: XACML is a good standard, but there is an open hook for obligations, we need to reach interoperable standards for these

HL: that is a separate work item from XACML
... trying to standardize all possibilities would be a never ending task

AM: in OGC we're thinking of a registry binding URIs to meanings

HL: the most we could do in OASIS is a core set, but no interest in managing a registry

RW: social process to agree on terms

HL: there will always be things you forgot to specify, some wiggle room is needed

TCB: standards are about nailing things down, options work against interoperability

ML: binding language extensions to specs

RW: obligation element provides an extension point. Experience from PrimeLife shows that matching is important to a binding agreement

We should allow this world to be open and not closed (i.e. extensible)

At some point in time the various parties need to reach agreement to achieve interoparability

e.g. "must understand" conditions

AM: such agreements can use references to the shared semantics

RW: how can we bridge communities to support re-use of Semantic Web definitions?

AM: we need an attribute which references shared semantics, or which is left out for proprietary semantics

HL: currently XACML spec doesn't require the attribute to be de-reference-able

RW: no need to change the schema, we just need to redefine the meaning of id

AM: differentiate between identifier and concept

(i.e. between a name for a concept and the concept itself)

AM: asking for a possibility for an attribute for a URI that could be dereferencable.

HL: why not just use a XACML refererence (a URN)

TCB: it should be a URI

HL: It is defined as a URI

RW: what AM means is that OGC can define a URI for a set of meanings

HL: you wouldn't need to do that very often

RW: you wouldn't need to dereference the URI on every use

(caching/expiry metadata)

ML: wrt XACML triigers would be defined as elements within obligations?

GN: yes (showing example on slide 10)

AM: are there any WS-* standards that could help?

RW: WS-Policy?

HL: no

GN: slide 9 defines semantics for formal matching

HL: not just matching, rather partial ordering

GN: yes

HL: anyone want to make closing remarks on what should be included in workshop report?

AM raises issue of shared semantics for terms like delivery which can be used by both parties

GN: we use URIs to point to P3P vocabulary

RW: we could introduce a formal ontology for a richer vocabulary

HL thanks everyone for participating and contributing to the workshop.

FSP: approached HAL to see how much work would be involved in getting OASIS XACML TC to accept a profile including the PrimeLife ideas.

HL: does this extend the PrimeLife schema?

FSP: yes, slightly

HL: we're trying to close of XACML 3.0, so the mindset off the TC is likely to unwelcoming to changes

<carrasco> Example (mutatis mutandis) http://www.iana.org/protocols http://www.iana.org/assignments/language-subtag-registry

HL: you would get more attention after our next face to face

AM: as long as the core isn't change, it isn't a real problem, right?

HL: yes

end of workshop

- DRAFT -

W3C Workshop on Access Control Application Scenarios

18 Nov 2009

Attendees

Contents