<trackbot> Date: 07 May 2010

<scribe> Scribe: Olaf Hartig

<scribe> ScribeNick: olaf

<pgroth> hi ivan

<Yolanda> thank you Olaf for scribing!

<Mark> did not find US tel # on site for today...

Yolanda: we want to learn more about security related issues in our use cases
... new members ...

<dgarijo> me

dgarijo: from UPM

<Mark> yolanda - pls fwd the US bridge tel # - is not on site

dgarijo: student project on provenance

paulo: what provenance projects?

<Yolanda> Bridge US: +1-617-761-6200 (Zakim) Bridge UK: +44.117.370.6152 Bridge FR: +33.4.89.06.34.99 Conference code: 98765

<Mark> zakim??? ?

tlr: most of the time we will be going through list of sec.issues in the use cases

<Mark> srry zakim...518-608-2244 does not work

<Mark> this is mark sartor

tlr: associating message with identity

<Yolanda> Mark: were you able to get on the phone?

<Mark> no...do not have correct US bridge #

tlr: ivan's signature assoc. with message -> conclude message was signed by ivan

<Yolanda> +1-617-761-6200 then conference code 98765

<Mark> ok, am in.... thx

tlr: complicated about RDF: mixing data
... what of these piece are reliable?

<Mark> aahh...Mark

tlr: early work by J.Carroll
... efficient canonicalization
... only for a subset of RD graphs
... blank nodes are a big issues
... signatures give useful additional information about the data
... what annotations can be made to graphs and subgraphs?
... discussion ...

<Mark> how about the overhead metadata (size and BW issue) related to this? what portion of the original data size..

Yolanda: can one be reliably rely on having a signature forever?

tlr: associating public key to everything not useful

this won't scale

<Mark> what about backing out problems...e.g., when we find out that the provenance was incorrect/bad (bad character...)

cert.authority is a 3rd party I trust

<Mark> call this transferred provenance..perhaps we can use this as a secondary level

tlr: relying on another party to verify the binding between the key and the party assoc. with it

<Yolanda> paul: i have to step out for a min, can you take on?

tlr: CAs allow for hierarichal structures

<Mark> my view is that we assign provenance to data, and to relationships (which may affect the data); should handle differently?

tlr: hence only a small amount of authorities required

<pgroth> sure

<Mark> need to assign levels of trust...i trust "person" 50%...

tlr: issues: don't trust "old" key
... ... based on outdated algorithms

<Mark> time may change things in relationships between entities (thereby trust); how do we acccount for this

<pgroth> any questions?

<tlr> +1 to that

JimM: comment: electr.signatures relevant for records also as a timestamp
... sign series of pages - hierarchy of signings
... learning from attacks on electronic records for RDF

tlr: how express signature semantics ? requires work
... library community has worked on these issues

JimM: difference with RDF is OWA
... RDF has not a hierarchy that can be facilitated

smiles: complication with provenance ..
... experiment data cannot always be signed
... b/c the potential signer is not available anymore
... experiment results are based on lots of input
... only some of which are relevant (for signing / provenance)

tlr: make statement on your own data - the data you have available
... don't rely on signatures of others
... what does is the semantics of the provenance metadata - what does it mean? (signatures are just a tool)
... sign a summary statement instead of the whole data

<JimM> I think it is always straight forward to have a third party sign subsets if the originator signs the'whole thing' -

<tlr> jimM, right -- if the consumer trusts that third party ;-)

<JimM> I read Newton's notebook and he said "F=ma"

<JimM> yep

Mark: once we find signatures and have a trail of provenance - what if the signature sources are gone?

tlr: that's an issue
... if the priv.key is public - everybody could have created the signatue

<Yolanda> i'm back paul, tnx

<JimM> only the public ey is needed to verify sigs, so the private key could be lost w/o causing trouble

tlr: be prepared for these possibilities if you want reliable provenance information

<pgroth> great

<tlr> It can get lost without causing trouble. It can't be disclosed without causing trouble. ;-)

<pgroth> that's why we need provenance, no?

<JimM> +1 :-)

tlr: to trust provenance statements a security system is required
... that system will be more complex

<JimM> identity of what?

<JimM> person or the thing being signed?

<pgroth> person

pgroth: some sort of identity other than using signature

<JimM> signatures don't eally identify a person - it is their posession of something (key material in this case) that is the ID part

tlr: other measures are possible

<JimM> signature is the way to bind that ID to this purpose applied to those bits

tlr: but signature provides a binding that an attacker cannot game with

<JimM> for the latter purpose, there aren't many good options.

<JimM> For ID, you can actually combine user/password, cryptocard, etc. with signatures to make managing them 'easier'

<pgroth> i guess then openid has this on the end

JimM: signature is a binding mechanism - not aware of other good mechanisms

tlr: openId let's me proof to another Website that I have access/conrol to another Web site

<pgroth> thanks!

JimM: similar to grid authority mechanism

Yolanda: Thomas please go through the use cases

<Yolanda> http://www.w3.org/2005/Incubator/prov/wiki/Security_issues_in_provenance_use_cases

tlr: review? or discussion?

Yolanda: 1st use case
... anonymized statements

<JimM> Shiboleth - an examle of an authority that will sign a statement about your qualifications w/o giving your name/all info known about you

tlr: hash a string

attach that hashed string to the message

if someone wants you proof ownership

tlr: show the string
... there is cryptography mechanisms that let's you do this

Yolanda: is a notarization service differnt from ... ?

tlr: these services may publish hashes of signatures and attach these to other signatures
... so that the chain cannot be broken easily

<pgroth> nope

<pgroth> that's from before

Yolanda: how to handle the issues that are raised?

trackbot, end telcon

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/signature/public key/
Succeeded: s/must/will/
Found Scribe: Olaf Hartig
Found ScribeNick: olaf

WARNING: No "Topic:" lines found.

Default Present: +49.308.937.aabb, pgroth, Yolanda, +49.300.aaee, raphael, Irini, olaf, smiles, Ivan, michaelp, SamCoppens, pmissier, +1.619.223.aaff, JimM, jcheney, Thomas, +1.518.608.aagg, +1.609.936.aahh
Present: +49.308.937.aabb pgroth Yolanda +49.300.aaee raphael Irini olaf smiles Ivan michaelp SamCoppens pmissier +1.619.223.aaff JimM jcheney Thomas +1.518.608.aagg +1.609.936.aahh
Agenda: http://lists.w3.org/Archives/Public/public-xg-prov/2010May/0001.html
Found Date: 07 May 2010
Guessing minutes URL: http://www.w3.org/2010/05/07-prov-xg-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report