Web Payments Telecon Minutes for 2012-03-06

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.

---------------------------------------------------------------------
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/

Received on Tuesday, 6 March 2012 21:52:03 UTC