IRC log of acas on 2009-11-18

Timestamps are in UTC.

08:18:21 [RRSAgent]
RRSAgent has joined #acas
08:18:21 [RRSAgent]
logging to
08:18:32 [rigo]
rrsagent, please set log public
08:18:54 [rigo]
chair: Hal Lockhart
08:19:12 [rigo]
08:19:21 [rigo]
scribe: tlr
08:19:27 [rigo]
scribenick: tlr
08:19:28 [tlr]
Topic: Hal Lockhart, The State Of Access Control 2009
08:19:31 [tlr]
-> paper
08:20:19 [mario]
mario has joined #ACAS
08:22:47 [elenat]
elenat has joined #ACAS
08:32:31 [carrasco]
carrasco has joined #ACAS
08:48:45 [tlr]
DC: If you don't know where the attributes come form, you don't know whether you can trust them.
08:48:57 [tlr]
... these statements come from "this party can issue this attribute"
08:49:15 [tlr]
HL: that information exists, it is outside of XACML
08:49:33 [tlr]
DC: you said the SecPAL approach wasn't feasible, and I'm disputing that.
08:49:42 [tlr]
DN: security and privacy of attributes -- is this about certifying attributes?
08:49:46 [tlr]
HL: CARML language
08:49:51 [tlr]
... look at IGF project on openliberty
08:50:09 [tlr]
... 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
08:50:13 [tlr]
... what properties are etc
08:50:52 [tlr]
RW: What kind of comments did you get for the privacy profile?
08:51:04 [tlr]
HL: That profile is extremely minimal -- just defines purpose attribute
08:51:09 [tlr]
... developed in 2.0 time frame
08:51:17 [tlr]
... looked at EPAL, and that looked like it was the only thing we needed to add
08:51:27 [tlr]
... various references to core spec
08:51:40 [tlr]
PS: purpose is for access control, not privacy
08:51:53 [tlr]
... restricting access based on purpose is access control, not privacy
08:52:02 [tlr]
RW: depends
08:52:16 [tlr]
TR: It is access control motivated by privacy
08:52:38 [tlr]
HL: healthcare scenarios
08:52:51 [tlr]
... presentation yesterday was very similar to XSBA (?) demos
08:53:03 [tlr]
... healthcare profile generated based on @character salad@
08:53:32 [tlr]
... dealing with things like emergency, etc etc
08:53:44 [tlr]
... on purpose -- often people say "not sure what people do in the future"
08:53:57 [tlr]
... but in the case of healthcare, often using specific systems
08:54:08 [tlr]
... so turns out not to be an issue
08:54:12 [tlr]
PS: emergency -- different policy?
08:54:18 [tlr]
HL: yes, attribute "emergency has been declared"
08:54:23 [tlr]
... more logging, less checking
08:54:43 [tlr]
GN: purpose is attached to resource as resource attribute -- for which purpose can the resource be accessed
08:54:47 [tlr]
... shouldn't this be part of the policy?
08:55:08 [tlr]
HL: think the semantic is that it's the purpose for which the data is collected
08:55:14 [tlr]
... the logic you're talking about is in the policy
08:55:35 [tlr]
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
08:56:22 [tlr]
HL: good comment
08:56:26 [tlr]
... side remark: the work we do is public immediately
08:56:51 [tlr]
... also, public comments
08:57:36 [tlr]
... -dev list for developers
08:57:59 [tlr]
... for XACML, separate list xacml-users which is supposed to be about issues related to design of policies
08:58:13 [tlr]
RW: interested in timing
08:58:19 [tlr]
HL: trying to close the box on 3.0
09:01:03 [tlr]
... expect selective implementation of profiles instead of giant switch-over
09:01:29 [tlr]
??: how difficult is it to get a profile accepted?
09:01:34 [tlr]
HL: except for timing -- easy
09:01:39 [caribou]
09:01:42 [tlr]
... in particular when you actually work on it
09:02:00 [tlr]
... "here's a document, I'm going to edit it" is a good way to get things done
09:03:04 [tlr]
RW: privacy attributes, privacy profile -- how to contribute?
09:04:03 [tlr]
HL: note only the core defines a schema -- administrative stuff uses new elements, those are defined in the core
09:04:12 [tlr]
GN: profiles only come out if new version?
09:04:17 [tlr]
HL: no, XSBA is on its own schedule
09:04:25 [tlr]
... but some of these things have dependency
09:04:28 [tlr]
09:04:56 [tlr]
HL: if doesn't impact other things, can move through -- more confusion in marketplace, but deal with
09:05:06 [tlr]
FSP: what about profiles that just use extension points?
09:05:10 [tlr]
HL: no single statement
09:05:19 [tlr]
... profiles have independent conformance points
09:05:26 [tlr]
... most require conformance with core as a precondition
09:05:38 [tlr]
... could use the definitions in export control with whole new policy language
09:05:44 [tlr]
... no one definition -- profiles can extend, narrow, ...
09:06:24 [tlr]
PS: a bit more what you're looking at for multi and hierarchical
09:06:26 [tlr]
HL: the answer would be long
09:06:28 [tlr]
... a lot of the comments and the changes proposed came from OGC work
09:06:30 [tlr]
... in addition to doing geospatial stuff, OGC were the first to using XACML in web services environment, srsly
09:06:48 [tlr]
09:06:50 [tlr]
09:07:11 [tlr]
topic: Bottom-Up approach for Compliance: The MASTER position (Emmanuel Pigout, Philip Miseldine, SAP Research)
09:07:18 [tlr]
-> paper
09:07:28 [tlr]
-> slides
09:08:23 [tlr]
rrsagent, draft minutes
09:08:23 [RRSAgent]
I have made the request to generate tlr
09:08:32 [tlr]
rrsagent, make record public
09:08:56 [tlr]
Meeting: W3C Workshop on Access Control Application Scenarios
09:25:15 [tlr]
ME: what kind of standardization do you envision?
09:25:24 [tlr]
EP: looking at OASIS as appropriate body
09:25:37 [tlr]
... not really an ontology; looking at OWL-S, WSMO
09:25:45 [tlr]
... some work done at the WSDL level to add semantics
09:26:24 [tlr]
GN: what is it you want to standardize?
09:26:25 [tlr]
EP: would like to standardize evidence model
09:26:28 [tlr]
... how you represent evidence
09:26:36 [tlr]
??: using PSL formulas to express these
09:26:48 [tlr]
... quantify what a particular service provides and do direct comparison?
09:26:53 [tlr]
... or have standard shapes of formulas?
09:26:59 [rigo]
09:27:00 [tlr]
... how do you benefit from using PSL form?
09:27:11 [rigo]
09:27:29 [tlr]
EP: policy -> PSL through BPEL annotations
09:27:52 [tlr]
... advantage of PSL is that in MASTER, at design time doing pi calculus, can do formal verification
09:28:14 [tlr]
... able to verify
09:28:48 [tlr]
... PSL can be translated
09:29:05 [tlr]
NP: Do you know work by Michael Gillieaux (sp?)?
09:29:19 [tlr]
EP: MASTER works together with TAS3 and PrimeLIfe
09:29:33 [tlr]
... compliance -- glue between trust, privacy etc
09:29:49 [accorsi]
Maike Gilliot <>
09:30:00 [tlr]
s/Michael Gillieaux/Maike Gilliot/
09:30:23 [tlr]
EP: ultimate purpose is to show that business is under control
09:30:37 [tlr]
Topic: coffee
09:58:04 [dsr]
dsr has joined #acas
10:05:59 [mib_rk6xfm]
mib_rk6xfm has joined #ACAS
10:09:21 [carrasco]
carrasco has joined #ACAS
10:10:06 [caribou]
Topic: Towards Standardization of Distributed Access Contro
10:10:18 [caribou]
10:14:22 [caribou]
-> paper
10:16:45 [rigo]
scribe: rigo
10:16:51 [rigo]
scribenick: rigo
10:23:08 [rigo]
you will lose obligations
10:23:42 [rigo]
ML: aggregation also supresses ??
10:24:38 [rigo]
... combination of various attributes, we don't do, we only do aggregation on one attribute, remains linear, check for circular refs
10:24:56 [rigo]
DC: if refer and refer, how would you know
10:25:04 [rigo]
ML: we do a dept search first
10:25:19 [caribou]
10:25:37 [rigo]
NP: do you compare on synatx or on something?
10:25:44 [rigo]
HL: just compare decisions
10:25:53 [rigo]
ML: and send them around PDPs
10:28:03 [rigo]
ME: model you're applying, is it true that root on top takes the decision for all the subnotes?
10:28:21 [rigo]
ML: basically yes, but we can also combine and decide on a lower level
10:28:47 [rigo]
HL: you're using the known policy evaluation mechanism
10:29:29 [rigo]
....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..
10:29:54 [rigo]
...I don't know how you approach distribution
10:30:05 [rigo]
ML: the PIP is querying
10:30:28 [rigo]
HL: don't want to specify distribution in the policy, you want to do that separately
10:30:50 [rigo]
ML: consider different users are querying, first operator is different for each user
10:30:57 [rigo]
...that's why we made it dynamic
10:31:05 [rigo]
HL: doing runtime resolution
10:31:10 [rigo]
ML: yes
10:31:34 [rigo]
MK: ??
10:31:50 [rigo]
ML: Secpal has no negative negations,
10:31:57 [rigo]
MK: datalog?
10:32:22 [rigo]
ML: we are purely based on XACML, negation solved by grant/deny
10:32:34 [rigo]
MK: what do you use for verification for privacy?
10:32:45 [rigo]
ML: as difficult as for the standard
10:32:45 [dsr]
(secpal has open world assumption)
10:34:30 [rigo]
Topic: Towards Modelling and Verifying Dynamic Access Control Policies for Web-based Collaborative Systems
10:34:37 [rigo]
rrsagent, pointer?
10:34:37 [RRSAgent]
10:39:53 [mario]
mario has joined #ACAS
10:48:22 [rigo]
HL: question is if you always end up with the concrete model or whether you get abstraction
10:48:46 [rigo]
MK: in many cases there are abstractions
10:49:16 [rigo]
ME: example policy, how can the formal system find out the weaknesses without knowing the security goals
10:49:29 [rigo]
MK: you should know the spec of your systems
10:50:27 [rigo]
...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
10:52:00 [rigo]
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.
10:52:39 [rigo]
DC: issue, if you write a policy and you don't yet about the issue, you can't say
10:53:09 [rigo]
MK: there are other steps they don't know and the formal model helps to discover
10:53:21 [rigo]
...may be only considered one way, there more
10:53:48 [rigo]
RA: finding ways for violation, so no policy specification
10:53:59 [rigo]
MK: can verify in the verification language
10:54:33 [rigo]
HL: properties: nobody can review their own paper...
10:54:44 [rigo]
..state the properties you are stating
10:54:50 [rigo]
DC: if you haven
10:55:05 [rigo]
..t tought about the attack, you won't get to it
10:55:44 [rigo]
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
10:55:57 [rigo]
NP: tool has own language?
10:56:00 [rigo]
MK: yes
10:56:19 [rigo]
ML: what is the key diff between datalog or secpal
10:56:47 [rigo]
MK: we don't use secpal or datalog, because doesn't work with our model
10:56:55 [rigo]
ML: advantage of X-Policy
10:57:52 [rigo]
MK: policy is expressive in web scenarios, in verification part, we check it with a model
10:58:05 [rigo]
...cannot implement with standard model checkers
10:58:19 [rigo]
LB: what doesn't work with Secpal
10:58:49 [rigo]
MK: some tokens are permitted or denied, we change state dynamically, secpal is stateless
10:59:02 [rigo]
ML: you make evaluation at each request?
10:59:27 [rigo]
MK: each request changes the state of the system, looking for credential in different states
10:59:45 [rigo]
ML: requested subreviewing is a state?
11:00:17 [rigo]
LB: with Secpal you can specifiy duty, verification of properties is out of scope
11:00:40 [rigo]
DC: we have stateful PDP, records state. It is possible to build it
11:00:44 [rigo]
HL: does it scale
11:00:52 [rigo]
DC: well.....
11:01:06 [rigo]
HL: general problem with duties and large scale systems
11:04:41 [caribou]
Topic: discussion
11:04:42 [rigo]
11:05:16 [rigo]
HL: standardization is not a goal in itself, if there
11:05:31 [rigo]
...define extension in the schema but profile the implementation
11:06:19 [rigo]
...bottom up place, charter constraint is on access control, as long as it is consistent with work
11:06:51 [rigo]
....I have concerns about attributes, that's where people are blocked, instead of all people around solving only for themselves
11:07:12 [rigo] much done in the past, we should explore that
11:07:51 [rigo]
....specs are built with extension points, so that company, some industry branches can use them
11:08:28 [rigo] many people do implement? Only if it is sufficiently broad, should go to TC, but we are not gatekeepers
11:08:46 [rigo]
...OGC is done in OGC is good example
11:09:26 [rigo]
TCB: different policy languages for spec.. All of these languages
11:10:26 [rigo]
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
11:10:55 [rigo]
HL: yesterday provision of dynamic policies, generalization would be easy
11:11:06 [rigo]
DC: extension would be policy-type
11:11:13 [rigo]
...just element-any as a choice
11:11:32 [rigo]
HL: imagine people could agree on that as it is such low impact
11:11:47 [rigo] many customers don't do schema-checking, too much cost
11:12:01 [rigo]
...if you could make that suggestion to comment list
11:13:08 [rigo]
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
11:13:52 [rigo]
...people were asking to put this in policy instead and instruct PDP to go get the data over there
11:14:29 [rigo]
HL: don't get confused with packaging/implementation and model. Any implementation will have the possibility to go fetching, but it is not efficient
11:14:59 [rigo]
...I have lots of environments that need high performance, so remote PDP wouldn't work
11:15:21 [rigo] just come into TC and push for your solution
11:15:47 [rigo]
...things happen because there are champions
11:17:23 [rigo]
...for 3.0 you can have policies about policies. creating dynamic policies, evaluated only in the context of that request
11:17:48 [rigo]
...when we define the schema, has to be XACML policy, DC wants any policy
11:18:02 [rigo]
AM: want where the attribute can be fetched
11:18:25 [mari1]
mari1 has joined #ACAS
11:18:25 [rigo]
HL: question is where you want to attach it, outside the policy
11:18:57 [rigo]
AM: outside the PDP, only selctor and designator, if in the request context we would have URI
11:19:04 [rigo]
...PDP would go and get..
11:19:44 [rigo]
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
11:20:01 [rigo]
AM: how to fetch is in the request context
11:20:17 [rigo]
DC: PIP lift context. We have a paper on it.
11:20:29 [rigo]
HL: References instead of values
11:21:11 [rigo]
RW: this is what the SW is about
11:21:29 [rigo]
AM: different context
11:21:44 [rigo]
HL: URI is a supported data type
11:21:54 [rigo]
AM: you have to define what it means
11:22:10 [rigo]
DC: environment attribute, then pass on URI
11:22:36 [rigo]
AM: you need to know what it is, so you have to specify in the request
11:22:47 [rigo]
...has 3.0 covered everything?
11:23:08 [rigo]
DC: we coverd in a way that it is conformant, but there is no standard way of doing
11:23:15 [rigo]
...done that in OGF
11:23:54 [rigo]
...GFD 157 GFD 159 as specifications from OGF
11:24:37 [rigo]
HL: most common argument I hear that XACML is too complicated, now I hear not complex enough?
11:25:21 [rigo]
RW: fetch attributes
11:25:31 [rigo]
AM: put references where to fetch
11:25:48 [rigo]
HL: whether you sent request or information in the request
11:26:26 [rigo]
AM: mobile client, mobile client needs to get context, that would explode mobile device,
11:26:55 [rigo]
...ref would allow you to discover that you're still in same request context, could be localhost
11:27:23 [rigo]
AM: attribute ref, URI, than PDP does it
11:27:42 [rigo]
HL: server has PDP and PIP and PIP is fetching
11:27:57 [rigo]
TCB: localhost as default and other info in that place
11:29:50 [rigo]
RW: how to connect SW
11:30:13 [rigo]
HL: PDP type information
11:30:20 [carrasco]
s/localhost as default and other info in that place/the URI should not be localhost/
11:30:45 [rigo]
ML: only thing you want to have is a comparison thing
11:30:53 [carrasco]
Something taking into account
11:31:05 [rigo]
...otherwise you only want to have a name attribute value pair
11:31:39 [rigo]
HL: function go over to this guy who understands... hasn't been explored so far
11:32:07 [rigo]
...XACML doesn't know anything about it, it's about strings as long as
11:32:24 [rigo]
Elena: XML doesn't allow to express relationships
11:32:42 [rigo]
...if the subject would be expressed in RDF, the relations could also be protected
11:33:59 [rigo]
DSR: relationship is just a resource
11:34:10 [rigo]
HL: could treat as resource, you have actions on it
11:34:57 [rigo]
GN: Relation in a social network is different from RDF relations
11:35:17 [rigo]
HL: you can model that as actions on resources, change persitent state on resources
11:35:30 [rigo]
11:35:35 [dsr]
rrsagent, make minutes
11:35:35 [RRSAgent]
I have made the request to generate dsr
11:36:00 [mario]
mario has joined #ACAS
11:36:19 [rigo]
12:13:12 [renato]
renato has joined #acas
12:33:57 [tlr]
tlr has joined #acas
13:18:53 [caribou]
scribe: carine
13:18:59 [caribou]
scribenick: caribou
13:19:33 [caribou]
Topic: Extending XACML for Open Web-based Scenarios, Pierangela Samarati
13:19:47 [caribou]
-> paper
13:22:25 [mario]
mario has joined #ACAS
13:22:55 [carrasco]
carrasco has joined #ACAS
13:24:32 [caribou]
RW: is propagation of AC part of your scope?
13:24:49 [caribou]
DC: OAuth?
13:25:11 [caribou]
PS: we will discuss this
13:32:19 [mib_l3n81s]
mib_l3n81s has joined #ACAS
13:45:18 [dsr]
Perhaps it would be better for the policy to separate the condition e.g. age > 18 from the accepted means to prove that
13:45:43 [carrasco]
13:49:14 [dsr]
this would allow the user agent to determine which means would minimize disclosure of personal data
13:49:37 [rigo]
PS: fancy negotiation doesn't work, need user interaction and reasoning and abstractions
13:50:22 [caribou]
HL: your 4 goals are independent from each other?
13:51:28 [caribou]
PS: abstractions and recursive reasoning are very much related to each other
13:51:55 [caribou]
RW: if you use ontologies you can use SPARQL for reasoning
13:52:38 [caribou]
PS: it's time to have a way to communicate the policy to the user
13:53:02 [caribou]
RW: there's a // activity at MIT called PAW (Policy-Aware Web)
13:54:47 [caribou]
PS: either you request the client to present everything, or you ask only if you don't find something
13:55:35 [caribou]
PS: closed-world assumption is if you don't have my age you deny access
13:55:46 [caribou]
... you should have to way to ask
13:56:20 [caribou]
DC: just present a bunch of referrals instead of attributes
13:56:32 [caribou]
... you have to trust the system not to pick too much
13:56:48 [caribou]
PS: a user proxy, e.g. wallet full of certificates?
13:57:13 [caribou]
DC: no, just present available referral
13:57:39 [caribou]
13:58:11 [caribou]
PS: then you need to tell a proxy all the referrals, and associated policies
13:58:56 [caribou]
DC: all my attributes are asserted by 3rd parties
13:59:14 [caribou]
... I only give the list of third parties you can get the attributes from
13:59:48 [caribou]
PS: I should not even be disclosing that I have attributes
14:00:08 [caribou]
DSR: the user wants to know why the service is asking the information
14:00:37 [caribou]
... if I give a list of what I could provide, it's much more than needed
14:01:20 [caribou]
GN: reasons for not storing at the server
14:01:28 [caribou]
... you have to go back to the user
14:01:40 [caribou]
DC: pull-model is an alternative
14:02:06 [rigo]
PS: but the issue here is support for the server not to reveal everything to the user
14:02:11 [rigo]
...need dialog for this
14:04:08 [caribou]
DC: in the pull-model, the conditions are not revealed to the user
14:04:24 [caribou]
[debate over privacy of the user vs. privacy of the server]
14:05:01 [caribou]
Topic: Obligation standardization, David Chadwick
14:05:11 [caribou]
-> paper
14:09:46 [caribou]
DC: [describing what's missing in XACML]
14:20:08 [caribou]
-> slides
14:22:02 [caribou]
HL: I would like to see a list of obligations
14:24:52 [caribou]
HL: the PDP does not agree, it's just doing predefined processing
14:25:21 [caribou]
... we don't have a model for the subject in the AC model
14:26:07 [caribou]
ML: the PDP is not doing semantic specific things
14:26:14 [caribou]
... just checking
14:27:21 [caribou]
ML: 5 types of relations between obligations = unrelated, conflict, contradiction, inclusion, subordinated
14:28:39 [caribou]
RW: sorry for repeating. in P3P, caching, ordered statements
14:29:00 [caribou]
... even if it was simple to read, the ordered thing confused people
14:29:49 [caribou]
ML: in the policy itself you have relations?
14:30:24 [caribou]
... obligations are ordered in execution order?
14:30:34 [caribou]
RW: it does not have obligations
14:31:45 [caribou]
ML: we specify relations because we can't specify order
14:32:13 [caribou]
... but we can easily describe the relations (thx to a unique ID)
14:38:03 [caribou]
[HL showing a slide "obligation families"]
14:38:59 [caribou]
RW: work on obligations in PRIMCluster
14:39:17 [caribou]
... Feed that to the XACML TC
14:39:47 [caribou]
HL: XACML TC has a history of submitted material
14:40:17 [caribou]
HL will send a pointer to this, Rigo to relay to PRIMCluster
14:40:35 [caribou]
=== coffee break ===
14:41:46 [dsr]
14:49:42 [dsr]
obligation family draft
14:49:45 [dsr]
15:03:23 [dsr]
we resume after the break
15:03:27 [dsr]
scribe: dsr
15:04:19 [dsr]
Topic: 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
15:04:38 [dsr]
15:05:17 [dsr]
GN steps up to the podium to give the first of 2 talks
15:07:09 [mario]
mario has joined #ACAS
15:09:00 [caribou]
Scribe: dsr
15:10:48 [carrasco]
carrasco has joined #ACAS
15:17:55 [dsr]
GN: we want to move away from disclosing your identity to proving selected attributes as needed for the task in hand
15:18:06 [dsr]
HL: XACML has been that way from the start
15:19:02 [dsr]
GN: a concert ticket can be considered as a kind of credential
15:19:24 [dsr]
HL: there is a large literature on this that refers to that as a capability
15:20:36 [dsr]
DC: you probably mean trusted LDAP rather than LDAP since there is no trust model for data retrieved from a vanilla LDAP server
15:20:43 [dsr]
GN: yes
15:22:10 [dsr]
GN: one question for different solutiions is whether attributes are dynamic or static, and can they be authenticated
15:22:41 [dsr]
(see slide 9)
15:24:55 [dsr]
GN: reference to an attribute as {id, issuer} may not be sufficient, you also want to know the credential type involved
15:25:39 [dsr]
DC: you could cover this in an ontology that defines abstract types
15:26:22 [dsr]
HL: you can define an attribute type as {id, issue, credential} if you want
15:27:34 [dsr]
GN: sometimes it is critical that several attributes are from the same credential, e.g. credit card and expiry date
15:28:02 [dsr]
DC: better example first name and last name
15:28:46 [dsr]
GN: say you want to establish that your name is the same on two credentials but not to disclose your name
15:30:16 [dsr]
GN shows example policy (slide 11)
15:32:39 [dsr]
GN proposes use of SAML to carry conditions on attributes and provisional actions
15:33:01 [dsr]
This is to convey this information to a user agent (a client)
15:34:26 [dsr]
HL: any kind of credential has to be bound to the issuer, and a request/session
15:35:06 [dsr]
One of the issue features is called "holder of key"
15:35:39 [dsr]
HL and GN to take the details offline
15:36:38 [dsr]
GN: SAML needs extension to support any kind of proof token and not be restricted to XML signature
15:37:31 [dsr]
(DSR agrees with GN that authetication shouldn't be part of the access control directly, and should be instead associated metadata)
15:39:00 [dsr]
??: What is the difference from X.509?
15:39:18 [caribou]
15:39:20 [dsr]
GN: we add a treatment of privacy
15:40:20 [dsr]
GN: we are proposing a generalization of existing technologies for use in access control
15:41:04 [dsr]
GN: X.509 is a special case of credential
15:41:42 [dsr]
Topic: PrimeLife Policy Language
15:41:53 [dsr]
15:43:53 [dsr]
GN introduces scenario of data subject communicating with data controller (slide 2)
15:45:07 [dsr]
Slide 3 introduces role of XACML for policies and SAML for conveying info
15:47:12 [dsr]
Sticky policy is a agreement of what data controller may do and must do in relation to data subject's personal data
15:48:03 [dsr]
15:49:47 [tlr]
tlr has joined #acas
15:50:42 [dsr]
Slide 8 summarises authorizations and access control. Note role of downstream access control
15:51:18 [caribou]
"aliens landing on earth" ?
15:52:07 [dsr]
an example of predefined trigger...
15:53:29 [dsr]
AM: XACML is a good standard, but there is an open hook for obligations, we need to reach interoperable standards for these
15:54:24 [dsr]
HL: that is a separate work item from XACML
15:54:52 [dsr]
HL: trying to standardize all possibilities would be a never ending task
15:55:26 [dsr]
AM: in OTC we're thinking of a registry binding URIs to meanings
15:55:57 [dsr]
HL: the most we could do in OASIS is a core set, but no interest in managing a registry
15:56:31 [dsr]
RW: social process to agree on terms
15:56:56 [dsr]
HL: there will always be things you forgot to specify, some wiggle room is needed
15:57:33 [dsr]
TCB: standards are about nailing things down, options work against interoperability
15:58:53 [dsr]
ML: binding language extensions to specs
16:00:08 [dsr]
RW: obligation element provides an extension point. Experience from PrimeLife shows that matching is important to a binding agreement
16:00:58 [dsr]
We should allow this world to be open and not closed (i.e. extensible)
16:02:12 [dsr]
At some point in time the various parties need to reach agreement to achieve interoparability
16:02:36 [dsr]
e.g. "must understand" conditions
16:03:26 [dsr]
AM: such agreements can use references to the share semantics
16:03:36 [dsr]
16:04:16 [dsr]
RW: how can we bridge communities to support re-use of Semantic Web definitions?
16:05:09 [dsr]
AM: we need an attribute which references shared semantics, or which is left out for proprietary semantics
16:05:54 [dsr]
HL: currently XACML spec doesn't require the attribute to be de-reference-able
16:06:37 [dsr]
RW: no need to change the schema, we just need to redefine the meaning of id
16:07:00 [dsr]
AM: differentiate between identifier and concept
16:07:19 [dsr]
(i.e. between a name for a concept and the concept itself)
16:07:58 [dsr]
16:08:58 [dsr]
AM: asking for a possibility for an attribute for a URI that could be dereferencable.
16:09:14 [dsr]
HL: why not just use a XACML refererence (a URN)
16:09:43 [dsr]
TCB: it should be a URI
16:09:49 [dsr]
HL: It is defined as a URI
16:10:32 [dsr]
RW: what AM means is that OGC can define a URI for a set of meanings
16:11:02 [dsr]
HL: you wouldn't need to do that very often
16:11:26 [dsr]
RW: you wouldn't need to dereference the URI on every use
16:11:48 [dsr]
(caching/expiry metadata)
16:13:01 [dsr]
ML: wrt XACML triigers would be defined as elements within obligations?
16:13:13 [dsr]
GN: yes (showing example on slide 10)
16:13:53 [dsr]
AM: are there any WS-* standards that could help?
16:14:02 [dsr]
RW: WS-Policy?
16:14:04 [dsr]
HL: no
16:14:58 [dsr]
GN: slide 9 defines semantics for formal matching
16:15:13 [dsr]
HL: not just matching, rather partial ordering
16:15:15 [dsr]
GN: yes
16:16:10 [dsr]
HL: anyone want to make closing remarks on what should be included in workshop report?
16:17:07 [tlr]
tlr has joined #acas
16:17:14 [dsr]
AM raises issue of shared semantics for terms like delivery which can be used by both parties
16:17:30 [dsr]
GN: we use URIs to point to P3P vocabulary
16:17:55 [dsr]
RW: we could introduce a formal ontology for a richer vocabulary
16:19:11 [dsr]
HL thanks everyone for participating and contributing to the workshop.
16:20:51 [dsr]
FSP: approached HAL to see how much work would be involved in getting OASIS XACML TC to accept a profile including the PrimeLife ideas.
16:21:02 [dsr]
HL: does this extend the PrimeLife schema?
16:21:13 [dsr]
FSP: yes, slightly
16:21:55 [dsr]
HL: we're trying to close of XACML 3.0, so the mindset of the TC is likely to unwelcoming to changes
16:22:02 [dsr]
16:22:03 [carrasco]
Example (mutatis mutandis)
16:22:35 [dsr]
HL: you would get more attention after our next face to face
16:23:52 [dsr]
AM: as long as the core isn't change, it isn't a real problem, right?
16:23:54 [dsr]
HL: yes
16:24:13 [dsr]
end of workshop
16:24:27 [dsr]
rrsagent, make minutes
16:24:27 [RRSAgent]
I have made the request to generate dsr
16:25:35 [caribou]
caribou has left #acas