PAW f2f Jan 2006

Dan ConnollyDan Connollyemail:
Daniel KrechDaniel Krechaim: eikeon
Daniel WeitznerDaniel Weitzner
David Hyland-WoodDavid Hyland-Woodaim: piprototypo
James HendlerJames Hendler
Lalana KagalLalana Kagal
Tim Berners-LeeTim Berners-Leeemail:

Thursday, 19 January , 2006

PAW face to face Minutes
January 18 and 19, 2006
University of Maryland, MIND Lab
Logistics information:

 MIT - Danny, Tim, Dan, Yosi, Lalana
 UMd - Jim, Daniel, David W., Yarden, Bijan (Vlad at risk due to plane delays)
 Other - Steve Cook
Wednesday, January 18

9A - 10:00:  Conference room available for coffee, wireless setup, last minute hacking, email, etc.
10:00 - 10:30:  Intro remarks, agenda review, AOB  (Jim, Danny)
10:30 - 12:00:  Demonstration project (David Wood)
  Demonstration - review slides (URI coming)
Looking at proxy (

   r167 | eikeon | 2006-01-17 21:59:36 -0600

 - implements 1st 3 use cases.
and server:
 - proof checking was working, sorta, but currently broken.

Looking at demo site

-would like to have a easy-to-run demo working to show others -- either a local proxy or something on the web

On the 401 page:
-make policy file a hyperlink
-add both incoming and outgoing headers on the page

-add disclaimer that this site has nothing to do with the Girl Scouts of America.

"set user" in the proxy config uses unsafe GET
LK: why does the proxy submit proof? The search for a proof should have failed
TBL: maybe it's a proof of something else.
(hmm... I wonder if the proxy knows what formula it's trying to prove.)
DK: actually, seems to be a bug/misconfig in the fake proof checking

How to reduce the complexity of the proof presented?
    -problem is lots of formulae quoted (and quoted and quoted).

Want to find the branch in the proof tree that leads to the conclusion.
Could move to a backward chaining
Need PML interface

Checker fails on 'judy'

DanC: pr:Conjunction? misnomer?
TimBL: AndElimination
DanC: ah, yes. Er... but what's pr:Extraction, then?

Next Steps for Demo -- priorities for 2006

Danny would like to see some decentralized user cases, involving 3-4 sites.  Jim reminded everyone that in order to avoid denial of service attacks, all burden of gathering data from third parties and creating a proof must fall to the client.
 Danny: the important thing about distributing the proofs is that you only rely on the party that authorized the access...
  Danny: we care a bit more about the distribution than the specific security policies

How much caching should the proxy do?
 What *kind* of caching should the proxy do?
Do we cache public keys?

Danny: "Multi-party transactions without prior coordination".

We need to nail down the use case(s) so we can build them

  Discussion of Directions and extensions
12:00 - 1:00 LUNCH (Pizza at Lab; Something for Yosi*)
 1:00 -
4:00  Demo technologies discussion


Continuing discussion on the scenario... Flickr + OpenID + WWW2009 conf website
1. Photo Henry stores his pictures on the Flickr website
2. Danny is the Flickr admin. Danny can have his own policy about how to process the access control policies of users. (ignore for now)
3. Henry's policy states that attendees of WWW 2009 and their families can access his pictures.
4. JimH attended WWW 2009.
5. JimH has a foaf page that lists the open id url of his family including Bob.
6. WWW 2009 has a list of foaf files of people who attended the conference.
7. When Bob wants to access Henry's pictures he uses his proxy to develop a proof that states that he has access. The proof should include that he is related to JimH (authentication by openID) and JimH attended WWW 2009.
8. Flickr checks this proofs using a proof checker and needs to reauthenticate Bob using openID.

Who should be doing the most work ... the client, server, the conf website ??

DanC: Proof checker algo is one of the most important (and interesting ?) parts of PAW

JimH: We assume that proof generation is harder than proof checking. Proof generation puts a burden on the server.

Lalana: A proof checker will impose restrictions on the kinds of policies that can be written. How does a user figure out what kinds of policies will be supported by a certain server ?

Danny: Is it possible to have a policy validator ?

JimH: If we limited the expressivity of policies to OWL-DL things would be easier because in OWL-DL there is a provable proof checker. Bijan said that we don't need separate proof generator and checker if we stay within OWL-DL.

DanC: There has to be agreement in terms of what builtins and functions are supported by a proof checker.

JimH modifies scenario to be compatible with existing girl scout use cases... Flickr is replaced by the website of Girl Scout Troop 42 and WWW 2009 by Girl Scouts of America. GSA has an algo to figure out whether someone is a member of GSA. This algo is given to troop42 and can either be an apache module, some python code or a rule. So a member does not have this algo and only the troop42 can prove whether someone is a member or not.

DanC: JimH from the scenario cannot be required to be authenticated via openid because it is done at real time and we cannot expect JimH to be around when Bob requests the pictures.

Danny adds to the scenario
foaf:maker of OpenID:B is mother of http://....foaf.rdf#jane
#jane is member of #gsa

How we prove the second statement ? GSA states that on their website.

JimH: The problem is that openid is not transitive. My mother knows my openid but I don't know hers.

DanC: open id is similar to email callback.

Danny: open id is a self signed secret.

Danny: What if gsa publishes open ids instead of foaf files.

JimH: You cannot pass on someone else's open id.

DanC: In the end we'll ground out in keys, shared secrets, and callbacks.

JimH: GSA has a checking service with a wsdl interface. This service will say yes or no based on whether someone belongs to the gsa. When you register to gsa, you get a secret (maybe url, key, signature, or serial number). Jane registers and now she has the key [jane-gsa-secret]. We assume that gsa remembers jane-gsa-secret. GST 42 policy says show that you're a girl scout. So does Jane have to give her secret to her mother ? If it has to be done in advance then our system breaks. It would be better for GST 42to come back and tell Jane's mom that she needs a gsa-secret from Jane. Jane and Jane's mom exchange this info off-band and Jane's mom tries again.

Danny works out the scenario some more ...
GST 42 trusts that a person will say who their mother is.
(#jane is member of #gsa) signed with gsa's private key. This is stored by Jane. What if Jane is not able to give this shared key to Jane's Mom. Can Jane's mom get a new shared key i.e. (#jane is member of #gsa) signed with gsa's private key

JimH: Jane's Mom has to somehow get the shared key from Jane.

Danny: GSA can have a policy that states that (i) if you lose the shared key, we'll email it to you, (ii) if you lose the key, you're outta luck, and (iii) we'll give your shared keys to your family. So Jane's mom can go to GSA and gets Jane's key.

JimH: Adds to the scenario
Photos can be seen by anyone who is in a GSA, their families, or anyone they permit.

DanC: Suppose GSA had a different policy and Jane's mom could not get Jane's key.

JimH: Danny's solution does not allow more than 4 entities in the loop. New scenario .. Photos can be seen by anyone who is in a GSA and their mothers. Bob has record of Jane's family. So Jane's mom asks Bob for what she requires in order to prove that she is Jane's mom. When you add this, Danny's solution fails. Distributed proof generation. GST 42 does not know whether the proof was generated by Jane's mom or someone else. Use PAW infrastructure in every section.. Jane's mom asks Jane for her key and Jane says why and Jane's mom says because I'm your mother.

David: We didn't want every family member to have an account on GST 42 in order to access pics. Jane has an accout on GST 42. The requester has an "account" with Jane. So requester authenticates to Jane and Jane authenticates to GST 42. This will scale.

DanC: This is similar to a two step Kerberos protocol.

JimH: How does this work right now : Jane's mom calls Jane up and Jane gives her the key. Jane's mom uses the key to access the pic. How do we do this on the web ?

JimH: Two steps, Jane's Mom asks GST 42 for the pics, GST42 says prove you're a member. In order to be a member, you must have a key. Jane's mom asks Jane for the key, Jane asks Jane's mom to prove that she is her mom. Jane's mom authenticates herself and Jane sends her key. Another scenario - To buy an item on a server you need a credit card number. To get my credit card there was a negotation between me and a credit card company. The credit card company authenticates me but the server does not know how that authentication was done. You can add another entity to the loop such as Denise. I give her my credit card number and she makes purchases for me. Distributed authorization works and is used often. We should support that in PAW. This cannot be done using Danny's solution.

[checking to see what lalana is getting from this; I/DanC got lost here.]

DanK: I think we need to formalize the notion of a family secret.

Danny: There is a "leakiness" in the credit card system.

Lalana : There is a dif between using signed statements about jane that force jane's mom to prove that she's Jane's mom and using a credit card number which implies that jane's mom is actually jane.

JimH: Stresses on distributed authentication and authorization. Each pair of entities in the loop will use PAW to authenticate and authorize each other which results in a token being given by one entity to another. An entity will figure out what needs to be provided to the server when the request fails and it obtains the policy that needs to be satisfied.

DanC: Its arbitarily hard to generate a proof. It might takes 50 years to find an appropriate proof for access.

DanC : The way visa cards work is that the number can be exposed to humans and not machines. Policy : I can buy something or I can delegate to someone to buy something. If we use shared keys it really limits us.

JimH: I don't necessarily want to use shared key.

DanC: Seller's policy : If an item costs less than $50 I'll give the item to anyone who presents a valid credit card number. The owner of the credit card is completely liable for this.

Danny: Delegation of authority happens without the proof checker knowing that the delegation occured.

Danny: Jane can share her secret with anyone she wants and the secret is all that is required to confirm that she is a girl scout.

JimH: If Jane's proxy goes to get a picture, the proxy shows secret and her access is granted. If Jane's mom goes to get a picture, her proxy needs to prove that she is Jane's mom and she needs Jane's secret to prove that Jane is a gsa member.

DanK: Giving someone your key may violate the policy between the initial two parties of the shared key.
JimH: Usecase 4
Policy : (?y photo release) <= (?x member #GSA) and (?y family ?x)
(?y family ?x) is checked from ?x's foaf page.
Out of band exchange between Jane and Jane's member so Jane's mom knows how to prove that she's Jane's mom.
Jane's mom knows  #Jane'sMom mother #Jane.
Jane knows #Jane member #GSA.
Given this information PAW should be able to handle requests from Jane's mom.

During the problem solving/proof generation if I get a 401 on one of the log:semantics I want to use PAW to solve that 401. You can either (i) fail and go out and try to solve the 401 before retrying the earlier proof generation or (ii) put the earlier proof generation on hold, complete the current 401 and then continue with the proof generation.

      cwm update (Tim)
TimBL, Yosi, Vlad:

      Rein update (Lalana)
Lalana: Working on an explicit delegation mechanism using public keys where delegation statements can be in different policy languages.

 4:00 - 4:15 Break

 4:15 - 5:00 Continued technical discussion, hacking, etc.

 5:00 - 6:00 informal time/email reading
     (Perhaps a demo of SWOOP- OWL Debugging, RDF edit tracking, ...)

 6:00 Dinner (MIND Lab members invited), Los Cabos restaurant

Thursday, January 19

9:00 - 9:30 Setup, Continental Breakfast provided (Something for Yosi*)
9:30 -  10:00 Pychinko in PAW demo (Daniel)
   Use of Pychinko in a Sem Web portal

10.00 am
Daniel gives demo.
[seems to be a rehearsal of a Friday presentation... to whom? eikon? do you know?] I/LK am not sure.
Project called profiles in terror.

JimH: We have a terrorism ontology in OWL.

DanK: You can browse by people, orgs, etc. You can also get social networks. All generated from our ontology. We use probabilities (3 out of 4) to infer certain property values i.e. same cell, same location, etc.

Vlad continues with the demo.
Vlad: Enable editing rules in SWOOP. Edna started working on an ALOG (missed that ??) reasoner in SWOOP. Using SWRL parser called Hootlet from Manchester. Shows how to create "a same affiliation as" rule in SWOOP. You can publish this rule from the internal SWOOP representation to N3. Shows the N3 of the "same affiliation as" rule.
DanK shows the inferences made by the "same affiliation as" rule added by Vlad.

JimH: Can use both class definitions and rules for making inferences within the project.

Vlad: Only using DL not ALOG inferences (?)

Lalana: How do probabilities work in the project ?

DanK/Dave: Not really using probabilities. If 3 conditions are true, we assume that a default value for a 4th property. An N3 rule.
DanK shows how different views of the ontology are possible i.e. Terror Activities, Kinship, ParentOf, which are inferences made by rules.

JimH: Can't click on a link to get more info. We use rules to go beyond just OWL. "Launch" button allows you to "tear off" the graph into a new window so you can continue browsing and looking at the graph at the same time.  

JimH: Would like to extend it to allow different users different rights to the data and rules.

Danny: Would be interesting to use a PAW front end and a TAMI back end to this project.

JimH: We use Pychinko for OWL reasoning.

DanK: When you hit rerun it deletes all inferences made and starts the inferencing process again. Can we make changes to the rete algo to allow incremental inferencing.

Bijan: Rete algo can already handle it (?)

DanK: We handle inconsistencies by showing all info and how inserted it. For example, X says Y is 6" and Z says Y is 6.2" and the ontology says people can have only one height. Our project shows both heights in red and leaves it to the use to resolve the inconsistency.

VS: Another way to resolve inconsistencies is to have an overriding policy that helps the user choose one of the heights (Not sure this is what was said. If someone remembers, please add it).

[what's that graph layout thing?]

[hover-over provenance/rule-name info... seems like a trivial version of the PML proof browser. possible integration point. --DanC]

10.37 am
DanC starts describing the use case we discussed yesterday.
Troop42 is a girl scout troop. It has a website ( that hosts pictures taken at girl scout meetings/jamborees. Its access control policy states that pictures can be accessed by current girl scout members and their families. Girl scout members are identified by statements signed by public key SK-GSA. GSA is a website for the Girl Scouts of America. Jane is not in Troop42 but is a girl scout and her mom is Betty. GSA has a public key that ends in 763. GSA signs a statement saying that Jane is a member of GSA.
(#jane member #gsa) signed by SK-GSA

#jane is short for the address of jane in her foaf file. http://......#jane
In that file there is a property mother that is the open id url of betty http://..... betty

DavidW: Can't we use foaf files as open id url ?

DanC: Open id urls must be HTML files. So if we use foaf files we'll be incompatible with the rest of the open id world.

DavidW: Then we insist that people have more electronic resources to maintain both foaf and html files.
DavidW: We can assume that we can find html pages from foaf files.

RESOLVED: Jane's foaf file points to Betty's html page (open id url) and Betty authenticates via open id.

David W: NOTE that we may choose in the future to work with the Open ID community to include FOAF support.

DanC: Betty has a proxy and she makes an http get for a picture on The server comes back with a 401 error and the policy that she must satisfy. Betty must come up with a proof that shows that she meets the policy. The server checks this proof and if the proof is valid, betty is given access to the picture she requested.

Danny: Proof generator finds that girl scouts' families can access the pic. And then tries to figure out who Betty's family is and comes across Jane.
Where is the key stored ?

Lalana: I believe we had decided that the key itself would be a paw resource and would be controlled by a policy. So there would be a negotiation between Jane and Betty which would lead to Betty getting the key.

VS: When a proxy makes a request, the server sends back a policy. Is the proof generated by integrating statements/info from sources that the server trusts ?
DanC continues with the usecase. The proof is

    (...763.sign) crypto:signs
        { <http://....#jane> memberOf <....#gsa> }.
    policy states that
        { (...763.sign) crypto:signs { ?who memberOf <....#gsa> } }
           => { ?who memberof #gsa }.
    policy states that
        { ?who log:says { ?who mother [openid
?pg] } }
        => { ?who mother
[openid ?pg] }.
    <...#jane> log:says
        { <..#jane> mother [openid?pg] }.

           [ a few more steps... ]

DavidW: Four cases, key is publicly available, key is behind username/passwd that Betty knows, key is a PAW controlled resource, key was passed out of band.
Danny: Jane's foaf file pointed to the key so betty knows how to find the key but it is a paw controlled resource. May contain hints about how to get the key or key can be available from the GSA website.

DanC: These rules about going out and getting the info from GSA will reside in the Rein engine. Are you OK with that, Lalana ?

Lalana: Hmm, I'll have to think about that.

DanC: Its possible to get a 401 error while generating a proof. So you have to run PAW recursively.

Tim: Does it change the architecture of PAW ?

DanC: No, probably just software engineering.

(DanC's brain does not explode...)

Lalana: Does cwm now call the proxy ?

Tim: Yes. Everytime you do a log:semantics instead of just doing a web get, we'll use the PAW proxy.

Lalana: Its going to be really difficult to debug.

DanK: cwm web gets should channel through proxy too.

11:25 am - 11:30 am Break

11:30 am JimH gives a presentation

Inconsistency and annotation
   Discussion of directions for research
   VS Subrahmanian, invited guest

   VS's work in ontologies is at

VS gives a quick defn. lattics. see also:

Lattice of t (true), f (false), L (bottom/don't know), T (top, inconsistent)


Rule :
B:v & A:u => C:v[]u
  t     T      t

As A:t and A:f we get the gub as T.

We can also handle sources
Sources X Four (lattice)
A: [{s1, s2}, t]

A: [{s2, s3}, f]

Annotated version of RDF without rules
(r, p, u) each element of the triple can be annotated with any value from the lattice.
We have a paper that describes this in detail. ... hmm... can't find this "Annotated RDF" by Udrea, Recupero, Subrahmanian paper per se.

JimH: Three interesting things. ... 1) Cwm has a mechanism to support annotated logic but does not allow you to change the kind of technique used such as lattice (?)  [jh - i.e. could we make some of this declarative using VS's framework or similar] , 2) What if I find two inconsistent policies in PAW, 3) Apply lattice stuff to trust management.

Lalana: Should we also look into belief networks and other schemes for trust management within 3) ?

JimH: Yes

VS: Annotated logic is useful when you want to have more than one annotation such as timeliness and trust.

[jh] -- propose we have some subset of us (incl. me, Vlad, Lalana, ??) to explore how we might proceed.

Lalana: I agree.

12:45 - 1:20 LUNCH (kosher)

break-out at lunch on proof ontology etc... TBL/DanC/Yosi, with Vlad watching

Yosi: steps the proof checker knows
(or at least  should know)ut

1. log:semantics
2. log:conjunction
3. log:conclusion (evil)
4. log:includes
TBL: let's combine log:includes and log:conjunction into log:supports, with a recursive proof.

Seems that pf:Conjunction corresponds to ^I, so tbl and DanC agree that ConjunctionIntroduction is a better name, perhaps abbreviated/labelled CI.

We didn't settle on a name to resolve Dan's tension between Extraction and ^E.


25 - 2:00 Discussion of publication plans, Nugget, goals
Demo: New use case to be written, calls to continue - progress reporting via minutes.
cwm: fix bug in --prove/--check; pychinko integration needs completion; cwm meetings will continue


JimH: Discuss publication plans and project management.

Danny: DavidW, are you co-ordinator of the demo.

DavidW: Yes.

JimH: Resolving current problems in cwm and moving forward. What are our plans ?

Tim: bug in the proof generation needs to be fixed. Integration with Pychinko needs to be completed.

JimH: Will the cwm team meetings continue ?

Tim: Yes. We'll review the cwm-pychinko integration during these meetings and decide when its done. Probably will be done by end of 2006. Need to include decimals to cwm.

Yosi: Cwm supports decimals now but it hasn't been released. It is in the tests but the tests have not been released.

Danny: Seems like the demo crew got stalled because of the cwm team. So how do we handle this ? Is there a timescale for when you think you'll be done enough for the demo to proceed.

Tim: Depends on Yosi's availability.
Lots of discussion about this.....

Danny: Proceeeding without the proof checking is not acceptable.

DanC: We can either wait till the bugs in cwm are fixed or we come up with a plan b.

JimH: I suggest we have a f2f in Feb and only Tim and Yosi attend :)
JimH goes thru presentation

Danny: I'd like to see the 4th use case done by the WWW 2006 conference.

DanC: Which use cases have we done so far ?

Lalana: Use cases we've done so far
Use cases at
The policies at
(Done without proof checking)

JimH: Status of the demo is that the policies have been written for the 3 "use cases" and the demo team has integrated the first two without proof checking.

JimH: I'd be happy if we can do the first 3 use cases
(as defined in the December slides) properly (with proof generation and checking) by WWW 2006.

Danny: Will be cool to add open id authentication into the existing 3 use cases.

DanC: I would like DanielK to work with me to get open id into PAW.

ACTION: DanielK to work with DanC to get open id into PAW proxy and demo server.

DavidW: There are some issues with open id that we have to work on. Such as during proof checking the checker will have to make a callback to the user to re-authenticate via open id.

JimH: DanC believes that he has a plan in mind, so we should not make any design plans right now.

Discussion on whether pychinko can generate proofs instead.

DanC: We can consider pychinko to be plan b. So whoever comes up with the proof generation and checking first gets used.

Tim: We need to decide on a proof ontology.

JimH: Proof ontology should be discussed during the cwm team meeting. We only care if it works.

JimH: We need a figure to show what we're doing for the NSF "nugget". We are considering that architectural diagram on Danny and I will be responsible for the NSF nugget. Can we use the image from David Wood's Aug05 slides ?

DanC asked for "Rein in PAW" omnigraffle source; LK seems willing to mail it to paw-team.

[[ it looks like PowerPoint is a nice diagram editor; is there any way to get diagrams out of it in SVG or some sort of XML? ]]

RESOLVED : Lalana to update her pics with David's f2f pic by this evening.

DanC: recall
  <lkagal> So, I still think the N3 formal semantics paper would be perfect for AAAI's track on AI & the Web.
  <vkolovski> I think it's a good idea to have a cwm systems paper for the journal of web semantics
  <timbl> Ok, so is that a plit then - Vad do the cwm paper ad Lalana do the N3logic paper?

DJW: Journal of Logic Programming... good venue?
Special issue.
several: yes

More info :

DanC: I'm happy to review .html and turn it into conference-happy latex/PDF. I'm less happy to review PDF. I encourage paper drafts to be checked in to SVN just like code drafts.

LK: OK, 1 Feb draft of AAAI paper

traditional CWM schedule includes Wed 1 Feb 2006 2:30pET

JH: I have a 2pET meeting that day, 1 Feb

PROPOSED: 11amET 1 Feb 2006 for PAW telcon to review AAAI draft, among other things
JH: cwm Zakim code?

DanC: and we try to have agenda email with that too. a day ahead, or a few hours anyway

N3 Logic - AAAI - Lalana
cwm systems paper - JLP - Vlad
  Paw paper -
?venue (CACM? etc.) - Jim to take for now
  IEEE Intelligent Systems - Danny's ISWC talk
Nugget - Jim

DanC:is there a canonical PAW papers-written list?
JimH: there's just 1 paper so far, cited on
JimH: ah... plus ws-policy conference paper

TimBL: hmm... talks? blog stuff?

DJW: my talk at iswc
 cf ayers blog. p4 iswc
ACTION DanC: cite from

>----------------------- CALL FOR PAPERS ------------------------
>Journal of Theory and Practice of Logic Programming
>Special Issue on
>Guest Editor: Massimo Marchiori
>Submission of papers:      : 2 May 2006
>Notification of acceptance : 19 Oct 2006
>Revised version of papers  : 11 Feb 2007
>Publication                : approx. end 2007
>**** WEB SITE


DavidW: Daniel, Lalana, and DanC we're going to have monthly telecons and use email and IRC and regularly. Can we start our telecons on Feb 14th at 1.00 pm ?

45 END of f2f for participants
 JimH: I declare the meeting adjourned.

45 - 3:00 PI meeting - Jim, Danny, Tim

JimH: Do we need to have a PI meeting ?



ACTION: David W. to put PAW demo slides on Web (accessible from Paw site, preferably in a non-MS format).  Jim to provide updated slides first.
ACTION DavidW: check permissions on Girl Scout pictures and be sure they don't object
ACTION: Daniel K. to change state-changing in demo proxy from GET to POST.
ACTION: David W. to update use case document to add four-party photo-publishing use case (family member wishes to view a photo).  Use the same names as the current use cases.

ACTION: JimH to think about/propose a rule editor for creating PAW policies in N3

Lalana to rewrite use cases including current one with the names used in the examples.
ACTION: DanielK to work with DanC to get open id into PAW proxy and demo server.
ACTION: Lalana to work on paper for AAAI's AI and Web track - deadline Feb 1.
ACTION: Vlad to work on Journal of Logic programming on the web
ACTION: Lalana to update her pics with David's f2f pic by this evening