JH: you need something smarter than P3P especially in machine to machine. There are things that let you delve deeper into objects. One problem is that there is a lot of data for users to handle
KS: There are ID providers who can host you
JH: That assumes constant connectivity which doesn't happen
KS: When you share, you have a consent framework. Problem is being connected. If shared data is signed, you might be able to resolve problems with a legal process - you have enough to prove whatshould have happened.
CMN: There are lots of data that people are simply not prepared to hand over, because you cannot guarantee that it won't be handed over
JH: People are not consistent about what data they want to hand out - they want to be able to take it back. There is also a lot of data - your fridge wants to know whether it can hand over the milk level to the egg company...
FR: This really does happen already.
JH: the trick is that as a user you need to be able to ddelegate away the consent, not be asked every time. But you need to be sure that the consent you gave out is being followed.
FR: Kapil is talking about having recourse when someone has broken the rules
KD: The possibility of giving your data and the granularity - you need to be able to say which data you share with whom, and what happens to them. You should have the possibility to recall the data, or correct them. (Or at the very least to see them).
JH: You need to delegate this too.
CMN: There are use cases where it is important to make anonymous statements, or to ensure that personal information cannot be spread beyond the person the data is about. This matches legal requirements
FR: It is a legal obligation to give access to data?
CMN: Yes. Most companies in Europe are probably in breach
JH: There are cases where granularity can be critical. We are getting into a zone where the industrial framework is manageable, but spreading this level of accuracy to the home scenario will introduce another set of problems. And you want to be sure that nobody hacks your insulin pump.
DR: What about usability - how do we improve that?
FR: I had envisioned that P3P would have standard templates, a negotiation, a handful of common choices.
CMN: I agree that it is obvious. Part of the problem is lack of screaming customers, and there is some progress. Hopefully the usability isn't covered by the same kind of patents that took out some of the useful stuff in P3P to start with.
JH: Turns out users couldn't care less about privacy - until they personally feel the pain and then it should have been fixed for them beforehand.
DR: Machine to machine communication isn't the same model as for people
JH: You can have the same model, but you need to visualise it differently. You need to develop it so that it is machine friendly from the start.
CMN: The next steps are going to be looked at in W3C workshop next week... we did start doing the stuff on basic certificates and SSL working or not...
FR: So imagine you are printing something at an airport, and there is a man-in-the-middle reading your private documents
JH: I may be a print-and-remember-and-send-to-your-rival
FR: So we get back to the need for a bond. The service description is vetted by a third party and I can call the police if something happens
KS: The spoof problem can be dealt with by certification.
FR: How do I validate the certificate of the printer I am going to?
JH: You print the signature key on the printer...
KD: We are heading to legal identity for machines.
KS: Verisign are looking at embedding images into certificates.
FR: The problem is that Verisign has the identity but I can't tell
DR: That's where you get a statement signed about which printers are where, and you add that to a note to a particular printer...
FR: Today at the office i need to know the name of the printer I want. It's no help to know the name unless I can bind the name clearly to a device
KD: We identify things as people through recognition, or delegated trust. There might be a model that we can use such as "someone I trust says I can use this printer".
FR: So if there is no spoofing I trust the room not to spoof a printer...
JH: You are assuming that the discovery is ... If you can only discover close things, e.g. by telling bluetooth to only find stuff within a few feet. The issue is if you are sitting in the lounge, using remote connectivity to discover, you don't know. You have to constrain the device to perform as the user expects. The user has an expectation, we have a neat technical solution, but we don't manage to match these things to each other. The invisibility of the process is sometimes too strong.
FR: Challenge is to remove spoofability - how do I know that I am talking to this printer I can see with no man in the middle.
KS: Certified image of that device might be one of the answers.
JH: There are 2D barcodes on things in Japan. You could use that as an ID to check against.
FR: But they are cheap enough to paste one over the other and make yourself a man in the middle.
DR: But then you're not going to use it.
KS: Must be tamper resistant
CMN: and difficult to duplicate
FR: If you dynamically generate a barcode, we can check it
DR: We are requiring a user to do something, too.
CMN: Which won't work at the "getting milk out of the fridge" level...
TC: Discussion was mostly machine - human-or-machine questions. What about human-human
JH: You don't need machines to mediate human-human communication
TC: Exchannging information with a remote doctor you do need mediation.
JH: It is more pertinent for people but exists for machines. It is really about reputation management...
KD: There is a Rule Interchange group at W3C...