Web Payments Community Group Telecon

Minutes for 2012-03-06

  1. Security Vocabulary
  2. Specifying Key Ownership
  3. Creator of a Digital Signature
  4. JSON-LD Signatures
  5. Expressing Encryption and Signature Data
  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.
Manu Sporny
Dave Longley
Dave Longley, Manu Sporny, David I. Lehn, Jeff Sayre
Audio Log
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: 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: 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.
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: 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: 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: none that i can think of
Manu Sporny: that document in IRC is a bit old 2005.
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: 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: 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: 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
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.

Created by the Web Payments Community Group. Shared with love under a CC-BY license.