See also: IRC log
<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[End of scribe.perl diagnostic output]