IRC log of acas on 2009-11-17

Timestamps are in UTC.

08:04:24 [RRSAgent]
RRSAgent has joined #acas
08:04:24 [RRSAgent]
logging to
08:04:39 [dsr]
Introductions by the chairs
08:04:50 [dsr]
We go around the room introducing ourselves.
08:05:27 [dsr]
rrsagent, set logs public
08:07:19 [tlr]
tlr has joined #acas
08:07:43 [caribou]
caribou has joined #acas
08:07:45 [dsr]
08:08:06 [dsr]
meeting: W3C Workshop on Access Control Application Scenarios
08:09:34 [dsr]
Topic: Benjamin Aziz, Slides
08:11:28 [rigo]
rigo has joined #acas
08:11:41 [dsr]
chair: Rigo Wenning, Hal Lockhart
08:12:28 [rigo]
08:12:37 [rigo]
chair: Hal Lockhart
08:12:45 [rigo]
scribenick: rigo
08:15:57 [elenat]
elenat has joined #ACAS
08:24:18 [samarati]
samarati has joined #acas
08:26:54 [rigo]
Hal: ??
08:27:07 [rigo]
Ben: it depends on DSA
08:27:32 [rigo]
Hal: if you have single file and data and you only want to show image, if offline
08:28:21 [rigo]
Ben: yes, if the policy says it shouldn't than it shouldn't . If the images was given, not the experiment, the image will be given, but not the rest
08:28:36 [rigo]
...having ACL on parts of the file is definitely an issue
08:28:48 [rigo]
Greg: enforcement of offline case?
08:29:05 [rigo]
...does this requires the XACML running on the machine?
08:29:20 [rigo]
Ben: yes, need XACML engine on client machine, PEP
08:29:48 [rigo]
Andreas: sticky policy, policy becomes a kind of license
08:30:01 [rigo]
hal: will be discussed further
08:30:35 [rigo]
08:32:35 [dsr]
Topic: Nick Papanikolaou on Towards an Integrated Approach to the Management, Specification and Enforcement of Privacy Policies
08:37:53 [rigo]
-- Hal was asking also about the offline case in previous session and about the access on a part of a file
08:38:10 [rigo]
-- Ben responded that both are needed
08:45:08 [rigo]
Andreas: transfer from US to DE sounds familiar
08:46:33 [Mario]
Mario has joined #ACAS
08:46:54 [rigo]
Tomas: It is worth the other way around
08:47:32 [rigo]
08:49:42 [Mario]
other way around would be better
08:54:33 [rigo]
Nick Papanikolaou == np:
08:56:38 [rigo]
TCB: lawyer and IT don't understand each other, don't want to understand some time
08:57:04 [rigo]
... language has to be clear enough so that lawyers can understand
08:57:39 [rigo]
...translation of OJ, sometimes fine translation, sometimes just plain translation
08:58:16 [rigo]
AM: have you looked into Creative Commons (CC), there is no enforcement (on purpose)?
08:58:49 [rigo]
NP: one person working on contracts, not tech person, several service levels, more controls if you pay more
08:59:52 [rigo]
AM: one CC use would be "for commercial purpose" under the following conditions
09:00:21 [rigo]
...cannot explicitly says commercial
09:00:32 [rigo]
ME == Martin Euchner
09:01:31 [rigo]
ME: legal stuff is fairly difficult to translate into formal lang. need some intermediate step. company policies are closer, can be translated, at what level you find the abstraction?
09:02:31 [rigo]
NP: ACL is very low level (unix, XACML), legal language is very high level, have to find common characteristics, these data can be accessed under following characteristics
09:02:59 [rigo]
... in paper some examples about structures informal, try to turn in more formal
09:03:08 [rigo]
Greg: translation manual
09:03:13 [rigo]
NP: yes
09:03:39 [rigo]
MTB: gap between natural language and formal is huge
09:04:27 [rigo]
HL: TC is very interested in projects. Please contact chair or co-chair
09:04:48 [rigo] of the diagrams, label doesn't match the text
09:05:33 [rigo]
HL: nature of the level
09:06:00 [rigo]
AM: has someone a GUI for the PAP
09:06:08 [rigo]
NP: that's a goal
09:06:30 [rigo]
HL: figuring what kinds of approaches may work
09:06:39 [rigo]
NP: yes
09:06:55 [rigo]
HL: have to agree what the constructs are
09:08:44 [rigo]
RW: consensus by ambiguity
09:08:58 [rigo]
DC == David Chadwick
09:09:33 [rigo]
DC: agreement on meaning is impossible
09:10:08 [rigo]
TCB: 1000 ambiguity can be burned down to 20 by formal language
09:11:03 [rigo]
... try to reduce ambiguities as much as possible, but don't try to remove all, will fail
09:12:05 [rigo]
Emmanuel Pigout == PG: we need to work from both sides to close that gap
09:12:24 [rigo]
RW: can IT deal with ambiguities
09:12:40 [accorsi]
accorsi has joined #acas
09:12:47 [rigo]
TCB: those are just bugs, we know how to deal with bugs, not easy
09:13:15 [rigo]
HL: several people talked lawyers, but formal language is talking about IT
09:14:05 [rigo]
PG: in Master we are using PSL to close that gap, do verification Mcalculus
09:14:55 [rigo]
... translating the controls that legislations try to put in place
09:15:20 [rigo]
NP: there is an interpretation and we can explore all the options that legal framework gives
09:15:44 [rigo]
HL: everybody agrees that hardest gap is between natural language and formal language
09:16:16 [rigo]
... create some kind of formal model and give that some verification points where you ask back
09:16:30 [rigo]
TCB: you still need some kind of bugzilla to clear the issues
09:17:17 [rigo]
HL: Ben, scientific data provided and share data. Do you have hopes that we can automate
09:18:13 [rigo]
Ben: data is evolving over time, additional prob. Customize policies to data, but haven't arrived there yet, perhaps transformations, what requirements to put on data
09:19:08 [rigo]
HL: prob in ACL is ACL calculus, means what is the comparison between ACL policy of A and ACL policy of B
09:20:12 [rigo]
Greg: scientific data, requirements in Primelife, it also applies to personal data. What are the policy of revealing that you're over 21
09:21:32 [rigo]
RW: scope must be narrow
09:21:48 [rigo]
AM: ACL policy is context dependent
09:22:26 [rigo]
... in US ID is shown for beer, even if you have grey hair
09:23:05 [rigo]
...could have an anon token on paper to go to the bar
09:24:38 [rigo]
....policy for accumulated data by service would be hard, so service should just forget, common criteria
09:24:52 [rigo]
SS: what about selling a token?
09:25:19 [rigo]
HL: information is collected, only known to a small number of people
09:25:35 [rigo]
PS: just need a credential
09:25:51 [dsr]
The token needs to be tied to the person, which means that verification could involve collection of personal data, e.g. finger print, iris scan etc.
09:26:14 [rigo]
AM: is there a possiblity if a service is accumulating data about a person, accumulation and policy is an issue
09:26:40 [dsr]
or more commonly photos
09:26:51 [rigo]
NP: over 21, you don't do electronically, plastic card "over 21"
09:27:23 [rigo]
HL: how do you prevent from giving it to your buddy
09:27:28 [rigo]
NP: no protection
09:27:56 [rigo]
HL: challenge people to have a different use case than legal age
09:28:55 [rigo]
Raphael: how to enforce policy, conflict, you want to control your data, therefor you must identify to control
09:29:10 [rigo]
...very complex prob, working on it
09:29:46 [rigo]
Greg: there are fancy crypto tools on service so that you don't collect data at all, zero knowledge proof
09:30:25 [rigo]
dsr: verified electronically, if its a human, the human will forget. Avoiding to collect
09:30:43 [rigo]
greg: in US they sweep passport in the bar
09:30:55 [rigo]
HL: they try to detect forgeries
09:31:49 [rigo]
TCB: people take hash from ear picture and have an ear scanner in the night club. Night club would have to invest a lot
09:32:17 [rigo]
DC: centralizing data in one place is a bad idea
09:32:43 [rigo]
...the more decentralized, the better it is.
09:32:50 [dsr]
The hash of the ear photo is personally identifying information, and privacy sensitive.
09:32:52 [rigo]
NP: Problem is to keep that up to date
09:33:26 [rigo]
09:54:12 [tlr]
tlr has joined #acas
10:07:38 [dsr]
we break for coffee
10:08:12 [dsr]
Topic: Laurent Bussard on Can Access Control be Extended to Deal with Data Handling in Privacy Scenarios?
10:10:17 [dsr]
scribe: dsr
10:12:27 [rigo]
scribenick: dsr
10:25:46 [dsr]
HL: re XACML as DH aware AC, SAML and XACML don't cover trust statements
10:27:51 [dsr]
LB: is XACML the right language for privacy enhanced access control?
10:28:46 [dsr]
DC: we don't believe that one global language will be practical, but the response is easier to deal with
10:29:41 [dsr]
HL: XACML's use of obligation isn't the same as in LB's presentation.
10:30:39 [dsr]
HL: upper/lower bound on languages is dependent on semantics of obligations.
10:31:45 [dsr]
LB: for PrimeLife, we are concerned with comparing obligations which isn't covered by XACML.
10:32:30 [dsr]
RW: this could be handled via Semantic Web for declarative statements as basis for matching.
10:32:31 [Gregory]
Gregory has joined #ACAS
10:32:53 [dsr]
RW: how does XACML handle tests for comparisons?
10:33:54 [dsr]
The next scheduled talk is cancelled as John Tolbert isn't here at the workshop.
10:34:34 [dsr]
HL gives a brief summary of the Boeing position paper on XACML for Export Control and Intellectual Property Protection
10:35:22 [dsr]
HL: excited about people bring use cases on defining XACML access control attributes.
10:36:15 [dsr]
HL: we introduced obligations and advice into XACML as part of 3.0
10:37:03 [dsr]
If you don't understand the obligations access should be denied, whilst advice is info to pass to the requester
10:37:49 [dsr]
HL: another new feature is ability to associated attributes with values (?)
10:38:24 [dsr]
We've started work on a profile for obligation families
10:38:54 [dsr]
We have stayed clear of addressing obligation futures
10:40:03 [dsr]
In reference to LP's paper, it seems to me that you need to specify obligation semantics.
10:40:27 [dsr]
LB: we tried to address a useful subset, but to allow for news to be added later
10:40:53 [dsr]
HL: I would be very interested for people to define obligation profiles
10:41:40 [dsr]
RW: one of the use cases is delete my data after 8 weeks, but deletion is triggered by a timer event and isn't an access control operation as such
10:42:11 [dsr]
HL: that is out of scope for the XACML TC
10:42:35 [dsr]
looking forward to DC's presentation tomorrow.
10:42:57 [dsr]
HL: number 1 use case people mention is logging access.
10:43:23 [dsr]
HL: responding to RW, there is a relationship to XACML attributes.
10:43:48 [dsr]
LB: triggers aren't always caused by access control operations
10:44:27 [dsr]
ML: you could think of this as an operation that is triggered by access control but deferred.
10:44:39 [dsr]
RW: time is important
10:44:59 [dsr]
HL: XACML doesn't constrain obligations in any way.
10:46:07 [dsr]
RA: OSL is a kind of temporal logic that is relevant to this.
10:46:18 [dsr]
I can provide a reference later on
10:46:51 [dsr]
DC: we are looking at putting other languages within XACML using a way to notify the language
10:47:19 [dsr]
RW: how do you address interoperability in that case?
10:47:42 [dsr]
HL: it's an improvement of just putting an identifier in XACML.
10:48:56 [dsr]
DC: lots of call outs that trigger obligations. Receiver will balk if it doesn't understand the embedded language
10:49:12 [accorsi]
M. Hilty et al. A Specification Language for Distributed Usage Control <>.
10:50:24 [dsr]
AM: if you ask a data base for all attributes of an object, the access control mechanism can test to see if the set of attributes is okay
10:50:57 [dsr]
the obligation is used as a filter to strip out attributes the requester isn't permitted to access
10:51:21 [dsr]
DC: we have a similar solution, but use a 3rd call out to the PDP as a gate
10:52:40 [dsr]
AM: when requesting a map, some parts may need to be blurred out/hidden. There is no mechanism to verify that the filtering has happened correctly
10:53:17 [dsr]
Filtering by obligations is one case, another is filtering by attributes and a third is blurring out or transforming the data before delivery
10:54:11 [dsr]
DC: if something fails, you should get an exception
10:54:57 [dsr]
AM: the output for geographical data may be a binary image and not something the PDP can check.
10:55:16 [dsr]
Is there another way of checking?
10:55:46 [dsr]
RW: we need to be clear on terminology, lawyers and techies using different terms causes confusion
10:57:21 [dsr]
HL: the alternative approach is to treat each entity separately for access control purposes.
10:57:58 [dsr]
But that doesn't scale well for non-discrete resources
10:59:22 [dsr]
RW: think of a shop, which needs a feedback channel why people leave the shop without making a purchase
10:59:57 [dsr]
Is there a feedback channel?
11:00:31 [dsr]
HL: XACML 3.0 does provide a means to listing which policies are relevant
11:00:39 [dsr]
11:01:12 [dsr]
HL: this doesn't answer AM's question of how to model complex resources.
11:01:50 [dsr]
AM: the server gets an SQL request which needs to be passed through the access control policy.
11:02:45 [dsr]
NP: a lot of scientific applications have many components within large files for which you want to control access to.
11:03:22 [Mario]
Mario has joined #ACAS
11:03:28 [dsr]
HL: AM's case involves continuous data which creates problems.
11:04:02 [dsr]
HL: would like to hear discussion about how Semantic Web can be used to describe access control policies
11:04:45 [dsr]
RW: CB has worked on this. I am wondering how XACML policies could be annotated.
11:05:16 [dsr]
How could that be exploited by the access control engine?
11:05:38 [dsr]
Where to put the annotation is also a question.
11:06:07 [dsr]
HL: there has been some discussion on RDF in the XACML TC, see our wiki
11:06:31 [dsr]
Some of this is outside the scope of XACML, e.g. on describing relationships between attributes.
11:07:00 [dsr]
But we don't have a lot of SemWeb expertise in the TC and would welcome some help.
11:07:22 [dsr]
RW: e.g. relationship between first and second names of people.
11:07:57 [dsr]
SemWeb is good for managing lots of metadata and performing queries.
11:08:37 [MarioL]
MarioL has joined #ACAS
11:08:55 [dsr]
RW: many natural language terms in policies can map to the same concept in the ontology
11:09:42 [dsr]
The metadata could help with translating high level descriptions into lower level formal ones.
11:10:25 [dsr]
DC: one of the things we want to see in the SAML profile is the ability to provide dynamic policies
11:10:48 [dsr]
HL: we missed that, but there is a reluctance to re-open things right now.
11:11:44 [dsr]
May be we have been too rigourous...
11:12:42 [dsr]
People trying to apply XACML to webservices are bringing further requirements
11:13:16 [dsr]
There are a lot of implementation choices...
11:13:57 [dsr]
DC: a generic infrastructure works provided you can take advantage of the context
11:15:35 [mari1]
mari1 has joined #ACAS
11:15:38 [dsr]
AM: an access request doesn't always have the information needed for access control, and you need to check the result of the data base operation to determine what access control decisions are needed
11:16:30 [dsr]
DC: what about doing something before obligation?
11:17:10 [dsr]
In my talk tomorrow, I will talk about checks before, during and after obligations.
11:17:47 [dsr]
HL: the policy could provide a filter to strip out data that the user shouldn't be shown
11:18:36 [dsr]
DC: we have been experimenting with this for obligations in XACML 2.0
11:19:12 [dsr]
HL: XACML 3.0 obligation families will help with that
11:19:57 [dsr]
RW: the SQL query can be analysed to see which tables/attributes will be involved.
11:20:33 [dsr]
Maybe the metadata could assist with a pre-query check
11:20:50 [dsr]
rrsagent, make minutes
11:20:50 [RRSAgent]
I have made the request to generate dsr
11:21:28 [dsr]
we break for lunch
11:22:51 [dsr]
some data gathering on restaurant suggestions for this evening
11:27:22 [dsr]
we will make a booking at 6:30pm
11:27:37 [dsr]
and walk straight there from he
11:27:43 [dsr]
11:27:51 [dsr]
rrsagent, make minutes
11:27:51 [RRSAgent]
I have made the request to generate dsr
11:37:43 [renato]
renato has joined #acas
13:00:47 [renato]
renato has joined #acas
13:04:15 [Mario]
Mario has joined #ACAS
13:07:03 [dsr]
dsr has joined #acas
13:08:31 [tlr]
tlr has joined #acas
13:09:18 [mari1]
mari1 has joined #ACAS
13:09:52 [tlr]
topic:, Ulrich Pinsdorf (Microsoft), Jan Schallaboeck (ULD), Stuart Short (SAP)
13:09:55 [tlr]
Scribe: tlr
13:09:57 [tlr]
-> slides
13:12:32 [Gregory]
Gregory has joined #ACAS
13:12:59 [carrasco]
carrasco has joined #ACAS
13:15:46 [tlr]
HL: Please explain legal requirement 1
13:15:52 [tlr]
... are these policies that are sticky to the data
13:15:57 [tlr]
... what is a communicated policy?
13:16:02 [Mario]
Mario has joined #ACAS
13:16:18 [tlr]
SS: Service has given a policy
13:16:26 [tlr]
... when the user wants to use portal and subsequently different service
13:16:28 [mari1]
mari1 has joined #ACAS
13:16:35 [tlr]
... wants to ensure that policy that was originally declared is respected
13:16:42 [tlr]
HL: Does user declare to the new service when composition changes?
13:16:47 [tlr]
... what are you trying to do?
13:16:51 [tlr]
SS: Policy is stuck to the data
13:17:03 [tlr]
... data and policy are sent (in this example) to temping agency
13:17:16 [tlr]
... do not want policy to be lost when there is chain of services
13:21:17 [tlr]
13:21:31 [tlr]
??: Are you assuming it's just an initial, immutable policy?
13:21:36 [tlr]
SS: It doesn't change.
13:21:42 [rigo]
rigo has joined #acas
13:21:55 [tlr]
??: In case of CV, may extract part of CV, so I've now got a new piece of data
13:22:08 [rigo]
13:23:34 [tlr]
SS: requirement to change one's mind after release of data.
13:23:43 [tlr]
??: that's hard, once data is relinquished
13:23:59 [tlr]
RW: if data is gone, there is no legal reason to have notice
13:24:05 [tlr]
... so requirement turns void
13:24:43 [tlr]
??: My understanding -- if data is given and policy is "delete in a year", and user changes mind -- they can't
13:24:52 [tlr]
RW: they can make up their mind in certain circumstances
13:25:34 [tlr]
... distinction is whether you can get out of a previous contract -- revocation of permission
13:26:24 [tlr]
... if you drill down, it's all common sense
13:27:18 [rigo]
13:27:29 [rigo]
(David Chadwick)
13:28:16 [tlr]
MCB: so you're assuming a standardized CV in XML?
13:28:20 [tlr]
... there's a standardized European CV format. ;-)
13:29:32 [tlr]
DC: revocation capability?
13:29:34 [tlr]
SS: not quite
13:29:41 [tlr]
DC: note that universities can revoke certificates
13:30:30 [tlr]
... if use SAML, assume short-term
13:30:44 [tlr]
RW: revocation can occur on behalf of institution or on behalf of data subject
13:31:04 [tlr]
DC: in second case, not revoking qualification, but right to use this
13:31:17 [tlr]
RW: multiple stakeholders in the model
13:31:20 [tlr]
... need to get relations right
13:31:24 [tlr]
... otherwise, get mixed up
13:31:34 [carrasco]
13:32:06 [tlr]
RW: sometimes better to start from protocol, some times better to start from real-world assmptions
13:32:18 [tlr]
DC: worse in SAML case with masquerade etc
13:33:03 [tlr]
HL: "give the secretary your key or signature" type of scenario
13:34:43 [tlr]
Topic:, Hannes Tschofenig, Martin Euchner (Nokia Siemens Networks), Alissa Cooper (Center for Democracy and Technology), Richard Barnes (BBN)
13:34:54 [tlr]
-> paper
13:35:03 [tlr]
-> slides
13:35:09 [carrasco]
Direct to the CV http://snurl/eu-cv
13:35:59 [rigo]
13:36:18 [rigo]
Topic: ITEF GEOPRIV Authorization Policies
13:36:23 [rigo]
rrsagent, pointer?
13:36:23 [RRSAgent]
13:36:47 [rigo]
13:43:32 [caribou]
14:01:58 [tlr]
TR: deployment and implementation experience?
14:02:20 [tlr]
ME: don't know
14:02:39 [tlr]
GN: what do you mean by "similar to creative commons"?
14:02:55 [tlr]
ME: concept of license needs to be understood, formalized, defined
14:03:56 [tlr]
GN: would it be specified in the common policy format
14:04:01 [tlr]
... or in English text?
14:04:13 [tlr]
ME: these are ideas; not very specifc; investigation necessary
14:05:28 [tlr]
RW: Do I understand protocol correctly that the device receives request to give geo data out, then policy is attached to geodata, service has to honor the policy
14:05:33 [tlr]
ME: yes
14:05:42 [tlr]
RW: why do they do this?
14:06:12 [tlr]
|: RW, PS: supermarket :|
14:06:42 [tlr]
RW: srsly, do they think the user's conditions will really be accepted?
14:06:58 [tlr]
ME: don't know the geopriv group's motivations
14:07:27 [tlr]
HL: Is the question about tech deployment or legal questions?
14:07:41 [tlr]
RW: consistency with social conventions is critical for deployment
14:08:21 [tlr]
... I'd love to impose my conditions on US immigration!
14:08:38 [tlr]
HL: understanding is that data is delivered, conditions are attached
14:08:52 [tlr]
... idea is that the recipient gets benefit of data only if they accept the condition
14:09:10 [tlr]
RW: they get both -- there's no negotiation, so they honor the conditions -- or not.
14:09:25 [tlr]
HL: absent more elaborate schemes, need to agree in advance that you'll abide by whatever conditions come with the data.
14:09:32 [tlr]
DC: that's the model we're working under in TAS3
14:09:44 [tlr]
RW: doesn't scale
14:10:40 [tlr]
DC: reduce cost of compliance
14:10:59 [tlr]
HL: scope is what's the range of what can be specified
14:11:08 [tlr]
... then you have the detailed conditions together with the dat
14:11:10 [tlr]
14:11:34 [tlr]
PS: company to company, can think of conditions being pushed
14:12:13 [tlr]
HL: the other way in which these things get set up is that you have organizations, then everybody agrees to the conditions
14:12:55 [tlr]
14:13:53 [tlr]
??: would perfectly agree that there has to be some kind of framework
14:14:21 [tlr]
... but obfuscation and transformation information might be useful
14:15:09 [tlr]
Topic: Controlling the unified portrayal of geospatial cross-border maps, Andreas Matheus, Universität der Bundeswehr München
14:15:17 [tlr]
-> paper
14:16:00 [rigo]
rrsagent, pointer?
14:16:00 [RRSAgent]
14:17:41 [caribou]
Topic: Controlling the unified portrayal of geospatial cross-border maps
14:19:22 [caribou]
s/Topic: Controlling the unified portrayal of geospatial cross-border maps//
14:24:13 [dsr]
appears to conflate context dependent styling and desire to show more or less data to people across the border
14:24:41 [tlr]
HL: What's the harm of rendering an interior part of Germany in the Dutch style?
14:24:55 [tlr]
AM: Don't take it that seriously.
14:25:00 [tlr]
HL: oh, so it's a motivating example
14:33:48 [dsr]
access control attributes corresponding to evaluating geometric functions over geospatial data
14:36:16 [dsr]
these attributes are then used for controlling access to that data
14:46:51 [dsr]
rrsagent, make minutes
14:46:51 [RRSAgent]
I have made the request to generate dsr
15:10:12 [caribou]
scribe: carine
15:10:18 [caribou]
scribeNick: caribou
15:10:52 [caribou]
topic: Using XACML for access control in Social Networks, Jaime Delgado, Universitat Politcnica de Catalunya
15:11:29 [caribou]
15:13:32 [caribou]
-> slides
15:14:04 [RRSAgent]
I have made the request to generate caribou
15:16:45 [caribou]
HL: doesn't the social wbe server know all that stuff [who i friend of who]?
15:16:56 [caribou]
JD: we need to express new semantics
15:17:04 [caribou]
HL: of policies or attributes?
15:17:30 [caribou]
... the policy does not know the semantics of the attributes foo or bar
15:17:46 [samarati]
samarati has joined #acas
15:17:59 [caribou]
JD: yes. But the way you operate on this information is new
15:18:47 [caribou]
??: in terms of validation, XACML does not have the capability of validating credentials
15:19:56 [caribou]
HL: the rules only say "compare this and that"
15:20:29 [caribou]
[point of order: several talking at the same time, debate deferred to end of session]
15:20:38 [caribou]
s/several/several people
15:31:33 [rigo]
Jaime: have implementation of a matching from ODRL to XACML and from MPEG21 to XACML
15:32:55 [caribou]
s/from MPEG21/e.g. MPEG21 license/
15:38:01 [caribou]
Topic: Helping users to manage the information they disclose to websites, Dave Raggett, W3C
15:38:12 [caribou]
-> paper
15:38:22 [caribou]
-> slides
15:38:47 [carrasco]
s/other way around would be better/other way around is not possible/
15:39:39 [caribou]
Rigo: ODRL was submitted to W3C
15:40:11 [caribou]
... push for it?
15:40:31 [caribou]
[Dave starts]
15:42:38 [caribou]
GN: if you identify at 2 places with the same assertions, it's linkable
15:42:47 [caribou]
15:46:11 [caribou]
DR: privacy policy is what data is collected, what for and how long it will be kept
15:46:40 [caribou]
... privacy assistant that describes the policies to help he user
15:48:29 [carrasco]
XML should be more readable for IT people than a legal contract -:)
15:49:01 [tlr]
now, let's talk about perl...
15:53:55 [elenat]
elenat has joined #ACAS
15:55:54 [caribou]
RW: you can generate human-readable policies from P3P
15:56:39 [caribou]
... lots of legalese don't say anything but "give us your data"
15:57:43 [caribou]
... we have never played with scenarios like OpenID, intermediaries
16:00:44 [caribou]
DR: lack of technology to implement some Directives
16:00:58 [caribou]
... market is on demand of more and more personal data
16:02:01 [caribou]
TCB: if the site is in the EU, it's easy, if the site is not, it's a problem
16:02:26 [caribou]
... in the cloud
16:02:58 [caribou]
Topic: On Frameworks for the Visualization of Privacy Policy Implications, Rafael Accorsi
16:03:10 [caribou]
-> paper
16:03:30 [caribou]
-> slides
16:15:53 [caribou]
HL: the analysis depends on the facts that you know the semantics of what the user is sharing?
16:16:00 [caribou]
16:16:23 [caribou]
RA: no more than 10 datatypes with agreed semantics
16:16:58 [caribou]
LB: you compare policy of the _systems_ and policy of the _user_, what do you mean?
16:17:19 [caribou]
RA: policy of the system is e.g. "I need your birthdate and your address"
16:17:43 [caribou]
LB: and policy of the user would be "I'll let you have this...if ..."
16:17:47 [caribou]
RA: yes
16:18:11 [caribou]
RW: visualize an xacml policy?
16:18:21 [caribou]
HL: seen that in a PhD
16:18:48 [caribou]
RW: insisting that semantics of XACML is needed
16:18:59 [caribou]
DR: in DL
16:19:49 [caribou]
HL: any other questions? Proposal to work on finding directions
16:21:51 [hlockhar]
hlockhar has joined #acas
16:22:11 [rigo]
Hello World
16:22:31 [rigo]
Topic: Sticky Policies
16:23:54 [world]
hello rigo
16:24:02 [tlr]
s/Hello World/
16:24:07 [tlr]
s/hello rigo//
16:24:21 [rigo]
sticky policy: policy information attached to data, a bit like in S/MIME
16:25:00 [rigo]
DC: could be like an obligation, whenever data is moved, the subsequent service has to take the obligation to pass the policy information on
16:25:23 [rigo]
...independed PEP that passes on the information on behalf
16:26:26 [rigo]
...reject if a service can't enforce the policy, problem renegate site, "we enforce everything"
16:26:55 [rigo]
...first should be transport the information back and forth
16:27:14 [rigo]
... this is an extension to XACML
16:27:38 [caribou]
GN: do you insist on the sticky policy being signed?
16:28:06 [caribou]
DC: no. It's up to the PEP to package it with the data
16:28:34 [caribou]
... what we want to do next is to define a std protocol, application-independent
16:28:42 [caribou]
... we haven't gone to that yet
16:29:13 [caribou]
GN: the sticky policy is dependent on the data poured in that channel
16:29:29 [rigo]
DC: we don't have a correct binding
16:29:42 [caribou]
DC: yes. we haven't reached that detailed spec
16:29:42 [rigo]
...between data and policy
16:30:12 [caribou]
GN: once the channel is set up, you put whatever data you wat in it?
16:30:16 [caribou]
16:30:20 [caribou]
DC: yes
16:31:00 [caribou]
RW: scenario with data on HTTP then sent by email then put in a SQL DB. How the policy survives?
16:31:17 [caribou]
DC: you can have a conformant gateway before the SQL DB
16:31:23 [caribou]
... it would store the policy
16:31:45 [caribou]
AM: it's ODC topic18
16:31:58 [caribou]
... a DRM framework, 2 years ago
16:32:06 [rigo]
16:32:12 [rigo]
former OpenGIS
16:32:52 [caribou]
... Data travelling from one service to another service, it goes into another DB
16:33:00 [caribou]
DC: travels with the policy?
16:33:08 [caribou]
AM: separately
16:33:28 [caribou]
... SAML assertions to protect the policy
16:33:58 [rigo]
ME: tls never had sticky policies
16:34:24 [rigo]
...we are talking about higher level policies
16:35:00 [nikos]
nikos has joined #ACAS
16:35:22 [caribou]
HL: you need trust, in downstream parties
16:35:48 [carrasco]
16:36:02 [dsr]
I wonder about web browsers, e.g. use of HTML forms and how the personal data in the form is sent along with a binding to the policy. Personal data may also be sent as part of an HTTP Authorization header, so the binding isn't simple.
16:36:22 [caribou]
DC: if you commit to give in data to someone, you can't unliaterally change the contract afterwards
16:36:39 [caribou]
16:37:04 [caribou]
... there are different scenarios
16:38:06 [caribou]
EP: can't we add the temporal aspect?
16:38:15 [caribou]
... (like cookies)
16:38:40 [caribou]
DC: yes, you can say "for 6 months" but if I change my mind, can I change it back to 3 months
16:39:02 [caribou]
DR: if it's agreed in the policy that you can change
16:39:04 [hlockhar]
means of policy expression
16:39:23 [hlockhar]
means of transporting and binding policies
16:39:37 [hlockhar]
trust of enforcement
16:40:00 [hlockhar]
combination with endogenous policies
16:40:05 [hlockhar]
16:40:37 [caribou]
RW: subsetting policies, you can only get more restrictive
16:41:05 [caribou]
... opposite of the data aggregation in semantic web, where you always add
16:41:20 [caribou]
... temporary aspect because of deletion
16:41:47 [caribou]
... datawarehouses are not intelligent
16:41:59 [caribou]
... sticky policies would make them intelligent
16:42:27 [caribou]
DC: metadata can be attributes, policies
16:42:51 [caribou]
HL: policies are not just metadata, commitment to do something
16:43:12 [caribou]
HL: are we in a position to implement sticky policies?
16:45:22 [caribou]
TCB: do we have policies for every URI?
16:45:30 [caribou]
s/policies/a policy
16:45:47 [caribou]
HL: DRM has solved the binding issue 20yrs ago
16:45:55 [caribou]
several voices: no
16:46:02 [caribou]
DC: no it's a trust issue
16:46:20 [caribou]
HL: agreement to standards.
16:46:24 [caribou]
... what's missing?
16:46:30 [caribou]
DC: performance?
16:46:57 [caribou]
HL: what user is going to specify a 1GB policy? :
16:47:23 [dsr]
In most cases the policy will be defined by the server, not the user
16:47:24 [caribou]
ME: trust depends on who you are
16:48:38 [dsr]
One missing piece is for the policy to indicate the legal jurisdiction
16:48:50 [caribou]
EP: do we have sticky policies smart enough to identify that someone's breaching a rule in some country?
16:49:14 [rigo]
ML: internal attributes
16:49:34 [rigo]
...don't want to give them away, some solution the crypto way
16:49:46 [tlr]
ScribeNick: tlr
16:49:52 [tlr]
DC: you're talking about the credential validation issue
16:49:52 [tlr]
16:50:04 [tlr]
... then you have a policy who are trusted issuers of credentials
16:50:13 [tlr]
... I may be the only trusted issuer for data about my friends
16:50:16 [tlr]
... that's a policy
16:50:45 [tlr]
??: financial criteria would be things you'd want to keep secret
16:50:51 [tlr]
... think about risk management for credit cards
16:51:01 [tlr]
DR: binding agreements betweent wo parties
16:51:05 [tlr]
... data subject and data controller
16:51:11 [tlr]
... agreement can't be reached unless both parties know what it is
16:51:18 [tlr]
... have to disclose what's supposed to be the agreement
16:51:20 [tlr]
RW: absolutely
16:51:48 [tlr]
GN: where does the sticky policy come from?
16:51:54 [tlr]
... I don't like the name of the supermarket problem
16:51:56 [tlr]
... but it's a problem
16:52:00 [tlr]
... have seen both side
16:52:00 [tlr]
16:52:04 [tlr]
16:52:05 [tlr]
16:52:17 [tlr]
GN: both policies present and match, or policy imposed?
16:52:24 [tlr]
... Rigo's point is that data controller is often the big guy
16:52:30 [tlr]
... who can then impose rules, option is take it or leave it
16:52:43 [tlr]
... in primelife, made some advances along the lines of "perhaps true, but can at least specify preferences"
16:52:47 [tlr]
... optimize matching procedure
16:52:56 [tlr]
... automate decision whether or not can live with criteria
16:53:03 [tlr]
... automation happening
16:53:11 [tlr]
HL: there have to be mechanisms for policy agreement
16:53:19 [tlr]
GN: sticky policy as match between preferences and policies
16:53:33 [rigo]
HL: add mechanism on policy agreement to the list
16:53:38 [rigo]
rrsagent, pointer?
16:53:38 [RRSAgent]
16:53:51 [tlr]
GN: downstream data controller to follow sticky policy
16:54:06 [tlr]
... downstream controller could propose policy
16:54:12 [tlr]
... sticky policy could be matched against that
16:54:16 [tlr]
RW: several hops
16:54:24 [tlr]
DC: whatever mechanism is developed must be recursive
16:54:34 [tlr]
HL: can spend a lot of time on potential approaches
16:54:39 [tlr]
... nail down what we try to accomplish
16:54:55 [tlr]
RW: some of this was raised by Greg
16:55:02 [tlr]
... experience from past is you say "need policy expression"
16:55:13 [tlr]
... it's more complex than just policy expression
16:55:19 [tlr]
... have always somebody come in with additional information
16:55:31 [tlr]
... ease of extensibility of policy language
16:55:36 [tlr]
... subsequent understanding of policy expression
16:55:40 [tlr]
... one of the biggest issues in this area
16:55:54 [tlr]
... one of my misunderstandings in semweb was
16:56:01 [tlr]
... policy, data, magic happens
16:56:08 [tlr]
... unfortunately, magic doesn't happen
16:56:27 [tlr]
DC: have to assume multiple policy languages
16:56:31 [tlr]
... and integrating them
16:56:57 [tlr]
RW: protocol level
16:57:01 [tlr]
DC: flag policies with language
16:57:07 [tlr]
RW: bites with stickiness?
16:57:35 [tlr]
RW: Must be able to consume multiple languages -- add to list
16:58:18 [tlr]
??: policy references instead of policies?
16:58:35 [tlr]
HL: "if you want a policy, call me" -- binding to reference, not to policy
16:58:39 [tlr]
... that's neat!
16:58:51 [tlr]
DC: In X.509 put a hash in
16:59:21 [tlr]
DR: not sure we need to assume multiple languages
16:59:31 [tlr]
... but extensibility and matching in presence of extensions
17:00:01 [tlr]
HL: too many languages already -- and yes, they're insufficient in ways we don't know yet
17:00:25 [tlr]
RW: P3P semantics for privacy -- not enough
17:00:31 [tlr]
... in access control, need more than just privacy semantics
17:01:03 [tlr]
... know in baseline policy language how to deal with proliferation
17:01:18 [tlr]
HL: hope change would be independent
17:01:23 [tlr]
... an XACML policy says "XACML" right on top
17:01:34 [tlr]
... would hope that binding, trust arrangement etc be independent of expression language
17:01:38 [tlr]
DR: for matching, need semantics
17:01:44 [tlr]
HL: combining, yes
17:01:47 [tlr]
RW: mustUnderstand
17:01:52 [tlr]
... baseline of what have to understand
17:02:18 [tlr]
HL: out of tine
17:02:22 [tlr]
17:02:24 [tlr]
... need for tools
17:02:29 [tlr]
.... any last words?
17:03:43 [tlr]
ME: not sure end users need to understand
17:04:06 [tlr]
SS: managing policies -- systems administrator
17:04:13 [tlr]
... user needs to remember
17:04:21 [tlr]
... sys admin might have hundreds or thousands of policies
17:04:39 [tlr]
RW: JRC Policy Editing tool
17:04:57 [tlr]
... very feature rich
17:05:03 [tlr]
... mind numbingly feature rich
17:05:13 [tlr]
... challenge for server is to reduce complexity
17:05:20 [tlr]
... challenge for user is "justice has to be seen to be done"
17:05:35 [tlr]
... can have all the tools of this world -- if people don't get the feeling that privacy happens, it's not worthwhile
17:06:07 [tlr]
??: object to "end users don't need tools"
17:06:25 [rigo]
17:06:36 [tlr]
17:06:51 [tlr]
ML: need some tools to specify policies, some tools to visualize how policies affect data
17:07:02 [carrasco] for posterity -:)
17:07:09 [tlr]
17:07:16 [dsr]
rrsagent, make minutes
17:07:16 [RRSAgent]
I have made the request to generate dsr
17:09:17 [hlockhar]
hlockhar has left #acas
17:55:00 [nikos]
nikos has joined #ACAS