Re: Web Payments Telecon Minutes for 2012-03-06

On 6 March 2012 22:51, Manu Sporny <msporny@digitalbazaar.com> wrote:

> Thanks to Dave Longley for scribing! The minutes for today's telecon are
> available here:
>
> http://payswarm.com/minutes/2012-03-06/
>
> Full text of the discussion follows for archival purposes at the W3C.
>

Thanks Manu

The owner issue came up in WebID

We originally had the reverse relation ( cert : identity ) but that was
removed

Now we have

<#me>  cert : key   <#publicKey>

It was generally held that you should not have two relations backwards and
forwards, but maybe your arguments on the call make sense ...

http://www.w3.org/2005/Incubator/webid/spec/#turtle

Would be nice to find a common solution!


>
> ---------------------------------------------------------------------
> Web Payments Community Group Telecon Minutes for 2012-03-06
>
> Agenda:
>   Ad-hoc Discussion About PaySwarm Vocabulary Documents
> Topics:
>   1. Security Vocabulary
>   2. Specifying Key Ownership
>   3. Creator of a Digital Signature
>   4. JSON-LD Signatures
>   5. Expressing Encryption and Signature Data
> Resolutions:
>   1. Adopt rdfs:owner to describe ownership of a resource on the
>      Web and use that to associate public keys with identities.
>   2. Use dc:creator instead of sec:signer to identify the entity
>      that created the digital signature.
>   3. Change sec:JsonldSignature to sec:GraphSignature2011
>   4. Remove sec:XMLSignature from the Security Vocabulary. Add
>      it back in if an application requires it.
>   5. Change sec:cipher to sec:cipherAlgorithm.
> Facilitator:
>   Manu Sporny
> Scribe:
>   Dave Longley
> Present:
>   Dave Longley, Manu Sporny, David I. Lehn, Jeff Sayre
> Audio:
>   http://payswarm.com/minutes/2012-03-06/audio.ogg
>
> Dave Longley is scribing.
> Manu Sporny:  Longley, Lehn, on the call, Jeff not sure, Pelle
>   not present, we're going to cover some vocab issues today instead
>   of the original agenda.
> Manu Sporny: We need to discuss the following vocabularies:
> Manu Sporny: http://payswarm.com/vocabs/security
> Manu Sporny: http://payswarm.com/vocabs/commerce
> Manu Sporny: http://payswarm.com/vocabs/creditcard
> Manu Sporny: http://payswarm.com/vocabs/payswarm
> Manu Sporny:  The first set of vocabs we need to discuss are in
>   IRC (security, commerce, credit card, payswarm).
> Manu Sporny:  These are all tied together in PaySwarm, making up
>   the spec. There's also the web keys vocab that has some overlap
>   with security.
>
> Topic: Security Vocabulary
>
> Manu Sporny:  We're going to discuss the security vocab to
>   discuss what needs to be changed/modified.
> Manu Sporny: http://payswarm.com/vocabs/security
> Manu Sporny:  Used to be called the signature vocab, we kept
>   changing it a bit because we have needed to add cryptography,
>   etc., so it is more appropriately named "security" because the
>   scope is wider.
> Manu Sporny:  We have classes for signatures, keys, etc.
> Manu Sporny:  Also for encrypted messages.
> Manu Sporny:  One change we need to discuss is how the security
>   vocab and the web keys spec will work together.
> Manu Sporny: http://payswarm.com/specs/source/web-keys/
> David I. Lehn: (btw, the source security doc has fancier
>   colorized text, not sure why that isn't in the main one)
> Manu Sporny:  The web keys spec is different in that it talks
>   more about web-based PKI, whereas the security vocab deals with
>   the specifics of the objects used in cryptography and signatures,
>   etc.
> Dave Longley:  From what I recall, there are a few minor property
>   naming issues - we were mixing security terms with vocabularies
>   like Dublin Core. [scribe assist by Manu Sporny]
> Dave Longley:  With respect to conflict between security and Web
>   Keys - they are separate concerns - the security vocabulary
>   defines terms that the webkey spec uses. The webkey spec defines
>   how the Web PKI will work. [scribe assist by Manu Sporny]
> Manu Sporny: configuration service - A Web service that is used
>   to publish the public Web service end-points and other public
>   configuration information for a key listing service. A key
>   listing service must publish this service at a top-level IRI
>   named/.well-known/linked- data-services. The document must be
>   available in JSON-LD compacted form and must include the
>   http://purl.org/web-keys/v1 JSON-LD context. The following key
>   must be present in the published document: wkey:publicKeyService.
> Manu Sporny:  The web key spec talks about publishing services
>   that help you configure clients (like the above service).
> Manu Sporny:  Therefore, I was thinking that's why we need two
>   different vocabs
> Dave Longley:  If there is nothing else that goes in the Web Key
>   vocabulary, then we're fine putting that in the security
>   vocabulary. We should wait on this, no need to make a decision
>   yet. [scribe assist by Manu Sporny]
>
> Topic: Specifying Key Ownership
>
> Manu Sporny: Another is is stuff like this: "ps:owner":
>   "https://payswarm.example.com/i/bob",
> Manu Sporny:  Assuming payswarm doesn't exist at all, ps:owner
>   doesn't make sense in the security vocab so it doesn't seem like
>   it belongs there.
> Manu Sporny:  You could claim that ownership is a security
>   concern so it should be in there?
> Dave Longley:  I think we'd be expanding the scope if we put
>   ownership terms in the security vocabulary. I think people may
>   find it odd to reference a security vocabulary to claim ownership
>   over a Web resource. [scribe assist by Manu Sporny]
> Manu Sporny: http://payswarm.com/vocabs/security#Key
> Manu Sporny:  So, the question is, we have a term "ps:owner" that
>   specifies the owner of a public key. Which spec should that be
>   part of?
> Manu Sporny:  You came across an ownership issue in the webid
>   spec also?
> Jeff Sayre:  yes we did.
> Manu Sporny:  Do you remember which term you used for it?
> Jeff Sayre:  I'd have to go back and dig through notes, it's been
>   a while.
> Manu Sporny:  This doesn't belong in the payswarm spec because
>   it's too specific, and it doesn't belong in the security vocab.
> Manu Sporny:  There isn't a general ownership vocab for the web.
> Jeff Sayre:  it's sort of a privacy issue, right?
> Jeff Sayre:  identity, privacy and part of security, etc, they
>   are all similar ideas.
> Jeff Sayre:  there needs to be some vocab term for owner, whether
>   its in the security vocab is a different issue.
> Manu Sporny:  yes, we agree, but where does it go?
> Manu Sporny:  Should we create a privacy vocab?
> Manu Sporny:  Larger companies are ignoring privacy/do not
>   link/do not track/etc there's a general need for this.
> Jeff Sayre:  it's hard to control your content if you don't have
>   a stake in ownership, so it is in a sense a privacy issue, more
>   so than security.
> Jeff Sayre:  from an individual stand point, an asset that is not
>   security claimed is a security threat to your personal ownership,
>   not necessarily a big threat, if there are mechanisms to prevent
>   hijacking.
> David I. Lehn:  i wonder if ownership is explicit in the semantic
>   web ... or is it more likely that you just have your identity
>   resource point off somewhere else and point at your public key?
>   you don't have the relationship going the other direction?
> David I. Lehn:  maybe we only need a forward relationship and not
>   a reverse one.
> Manu Sporny:  if you go to a public key url it has to be able to
>   say who the owner of the key is.
> Dave Longley:  I agree, I don't think we should make ownership a
>   uni-directional link. [scribe assist by Manu Sporny]
> David I. Lehn:  That's fine with me, just putting it out there as
>   an option. [scribe assist by Manu Sporny]
> Dave Longley:  Also, not sure if privacy is the right term
>   either, ownership isn't necessarily a privacy thing. [scribe
>   assist by Manu Sporny]
> David I. Lehn:  Does this need to be a generic property? Could we
>   use sec:keyFor? [scribe assist by Manu Sporny]
> David I. Lehn:  does it have to be generic? should it be specific
>   to each circumstance?
> David I. Lehn:  instead of just a catch-all property for
>   ownership?
> Jeff Sayre:  yes, owner is a broad term, you have profiles,
>   accounts, assets, keys, all of these can be owned by something.
> Dave Longley:  Yes, we use this stuff extensively - profiles own
>   identities. identities own accounts and keys, etc. [scribe assist
>   by Manu Sporny]
> Manu Sporny:  i could talk with who is in charge with the rdfs
>   vocab (dan brickley, guha, etc).
> Manu Sporny:  maybe we can create rdfs:owner and use it and push
>   w3c to adopt it.
> Manu Sporny:  maybe in a few years they will adopt it.
> Manu Sporny:  it would only stop reasoning on data, i don't think
>   it would affect payswarm.
> Manu Sporny:  (to adopt rdfs:owner)
> Manu Sporny:  i am a member of the rdf working group, i'll raise
>   this over there.
>
> PROPOSAL:  Adopt rdfs;owner to describe ownership of a resource
>   on the Web and use that to associate public keys with identities.
>
> Dave Longley: +1
> Manu Sporny: +1
> Jeff Sayre: +1
> David I. Lehn: +1
>
> RESOLUTION: Adopt rdfs:owner to describe ownership of a resource
>   on the Web and use that to associate public keys with identities.
>
> Topic: Creator of a Digital Signature
>
> Dave Longley:  We were thinking about trying to re-use dc:creator
>   instead of sec:signer for signatures on a graph. I think the
>   current implementation uses dc:creator instead of sec:signer.
>   [scribe assist by Manu Sporny]
> Manu Sporny: http://payswarm.com/vocabs/security#signer
> Manu Sporny:  i don't see a reason to create a new term for this
>   (sec:signer) when dc:creator will do.
> Jeff Sayre: There's also <sioc: has_creator>
> Manu Sporny:  also, we might try to put ownership in dublin core
>   (as an aside)
> Manu Sporny:  unfortunately sioc:has_creator must have a range of
>   a user account that made the resource
> Manu Sporny:  which may be too specific
> Manu Sporny:  we could make a ps:identity a subclass of
>   foaf:online-account to make that work
> Dave Longley:  what advantages would there be with choosing
>   sioc:has_creator over dc:creator
> Manu Sporny:
>   http://dublincore.org/documents/usageguide/elements.shtml
> Manu Sporny:  none that i can think of
> Manu Sporny:  that document in IRC is a bit old 2005.
> Manu Sporny: http://dublincore.org/documents/dcmi-terms/
> Manu Sporny:  there is the new link in IRC for dublin core
> Jeff Sayre:  another possibility is that it would be easier to
>   have sioc extend that.
> Jeff Sayre:  i bring that up because sioc is very targeted
>   towards social communities online and payswarm is closely tied to
>   that too.
> Jeff Sayre:  they are heavily user-centric so there are limits to
>   sioc now, but it might be worth considering.
> Manu Sporny:  i'm leaning towards just using dc:creator, it's
>   just a simple, base vocab.
> Manu Sporny:
>   http://dublincore.org/documents/dcmi-terms/#terms-creator
> Manu Sporny:  sioc is very specific to online communities and
>   since we are talking about a security vocab and who created a
>   signature versus the specificity of sioc.
> Jeff Sayre:  that makes sense.
> Manu Sporny:  the documentation for dc:creator (entity primarily
>   responsible for creating the resource) makes perfect sense.
> Manu Sporny:  i'm scanning quickly to see if there is already the
>   concept of an owner in dublin core.
> Manu Sporny:  there's provenance
> Manu reads the description of provenance to the group:
>   http://dublincore.org/documents/dcmi-terms/#provenance
> Manu Sporny:  i can talk to tom baker and see if they'd be
>   willing to put owner into dublin core.
> Dave Longley:  they might also have a suggestion for us to use
>   something else if what we're using is not appropriate.
> Manu Sporny:  i will talk to the rdf group and dublin core about
>   this.
> Manu Sporny:  i think have a decision, we're going to use
>   dc:creator.
> Manu Sporny:  to replace sec:signer.
>
> PROPOSAL:  Use dc;creator instead of sec;signer to identify the
>   entity that created the digital signature.
>
> Dave Longley: +1
> Manu Sporny: +1
> David I. Lehn: +1
> Jeff Sayre: +1
>
> RESOLUTION: Use dc:creator instead of sec:signer to identify the
>   entity that created the digital signature.
>
> Topic: JSON-LD Signatures
>
> Dave Longley:  We may want to add a few things in here like
>   nonces and dates to the signatures. [scribe assist by Manu
>   Sporny]
> Manu Sporny: http://payswarm.com/vocabs/security#nonce
> Manu Sporny:  We do have most of that in there already. [scribe
>   assist by Manu Sporny]
> Dave Longley:  There is a more complex issue - normalization in
>   JSON-LD. Having it be generalized will change the value. [scribe
>   assist by Manu Sporny]
> Manu Sporny: http://payswarm.com/vocabs/security#JsonldSignature
> Manu Sporny:  the whole reason we have JsonLdSignature and
>   XmlSignature is because we have multiple parameters that go into
>   a signature.
> Manu Sporny:  so those types tell you what parameters to use.
> Manu Sporny:  in this case the parameters include the
>   normalization method, digest method, and signing algorithm.
> Manu Sporny:  we really just need to change the name
> Manu Sporny:  JSON-LD normalization will be changing to operate
>   on triples.
> Dave Longley:  Maybe we want to split this out into different
>   parameters? [scribe assist by Manu Sporny]
> Manu Sporny:  We didn't want to give people too many choices...
>   [scribe assist by Manu Sporny]
> Dave Longley:  we don't want people to mix and match and create
>   interoperability problems.
> Manu Sporny:  right, so we should have a single type that
>   specifies all the properties.
> Manu Sporny: sec:SecureGraphSignatureV1
> Dave Longley:  a little redundant.
> Manu Sporny: sec:GraphSignatureV1
> Jeff Sayre: +1
> Dave Longley: +1
> Jeff Sayre:  2011 does refer back to the normalization method
> Jeff Sayre:  so it does make sense.
> Manu Sporny:  i have a slight preference to including date,
>   though if the year is 2020 it might seem archaic :)
>
> PROPOSAL:  Change sec;JsonldSignature to sec;GraphSignature2011
>
> Manu Sporny: +1
> Dave Longley: +1
> David I. Lehn: +1
> Jeff Sayre: +1
>
> RESOLUTION: Change sec:JsonldSignature to sec:GraphSignature2011
>
> Manu Sporny: Do we really need this:
>   http://payswarm.com/vocabs/security#XmlSignature
> Jeff Sayre: http://purl.org/jsonld#UGNA2011 404s
> Manu Sporny: Yeah, it isn't setup yet... :)
> Jeff Sayre: :)
> Manu Sporny:  my argument to remove XmlSignature is that no
>   systems are using it yet. We can always add it.
>
> PROPOSAL:  Remove sec;XMLSignature from the Security Vocabulary.
>   Add it back in if an application requires it.
>
> Manu Sporny: +1
> Dave Longley: +1
> Jeff Sayre: +1
> David I. Lehn: +1
>
> RESOLUTION: Remove sec:XMLSignature from the Security Vocabulary.
>   Add it back in if an application requires it.
>
> Manu Sporny:  What about sec:cipher? [scribe assist by Manu
>   Sporny]
> Dave Longley:  change it to sec:cipherAlgorithm? [scribe assist
>   by Manu Sporny]
>
> PROPOSAL:  Change sec;cipher to sec;cipherAlgorithm.
>
> Manu Sporny: +1
> Dave Longley: +1
> Jeff Sayre: +1
> David I. Lehn: +1
>
> RESOLUTION: Change sec:cipher to sec:cipherAlgorithm.
>
> David I. Lehn: might want to look at latest source too. it has
>   Digest too. http://payswarm.com/specs/source/vocabs/security
>
> Topic: Expressing Encryption and Signature Data
>
> Manu Sporny:  What about sec:data? [scribe assist by Manu Sporny]
> Dave Longley:  We need to be clear about the scope... more than
>   just data associated with the signature. [scribe assist by Manu
>   Sporny]
> Manu Sporny:  we have vocabulary terms that are required to make
>   the signature class self-describing
> Manu Sporny:  right now you can look up the @type for a signature
>   and figure that out
> Dave Longley:  We want to prevent people marking things up in the
>   wrong way, we have to be able to support saying what the digest
>   algorithm is. [scribe assist by Manu Sporny]
> Dave Longley:  It's just an error to specify the signature
>   algorithm and the digest algorithm in the same object. [scribe
>   assist by Manu Sporny]
> Manu Sporny:  The digestAlgorithm term description should
>   describe a signature algorithm, not a signature. [scribe assist
>   by Manu Sporny]
> Dave Longley:  it could be used to describe signature, but not
>   also when @type is specified.
> Dave Longley:  the example should change.
> Manu Sporny:  the security vocab should be close to be being
>   finished.
> Manu Sporny:  Good call, we'll chat again in two weeks.
>
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: PaySwarm Website for Developers Launched
> http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/
>
>