Web Payments Community Group Telecon
Minutes for 2012-06-12
Updates to the PaySwarm implementation
Web Keys: Removing prefixes & context management
Web Keys: Key Registration Process
Web Keys - Discovery
Web Keys - Messaging
Web Keys - Permission and Access Rights Delegation
Web Keys - Key Revocation and Expiration
Dave Longley, Manu Sporny, David I. Lehn
Warning: Your browser does not support the HTML5 audio element, please upgrade.
Dave Longley is scribing.
: on the agenda we have updates to the implementation (mainly switching from c++/mysql to node/mongo)
... then the rest of the call will focus on updates and finalizations we need to make to the web keys specification.
... is there anything else that we need to discuss?
Topic: Updates to the PaySwarm implementation
: ok, so recently dave longley implemented the payswarm spec in node/mongo rather than in c++/mysql.
... development on it was going slower than we would have liked, so we switched technologies.
... this way we can make more rapid progress implementing things in the spec and other technologies, etc.
... dave would you mind doing a high-level overview on why we switched, etc?
: Sure... in terms of performance, we weren't seeing an issue with C++ and MySQL... that implementation was performing well. [scribe assist by Manu Sporny]
: However, we were pushing off the need to scale out to further down the road... scaling out would've required us to write more custom code in C++ and MySQL. [scribe assist by Manu Sporny]
: We also don't need to write sharding code for the database - use MongoDB instead. We wanted to deal with transaction processing more asynchronous. [scribe assist by Manu Sporny]
: We wanted to move to a more asynchronous transaction processing engine - works well with non-transactional engines. MongoDB is better for this use case. [scribe assist by Manu Sporny]
: ok, thanks for the overview, for the near future we plan on using this code/technology stack?
: This was mostly about accelerating development speed and ease of implementation. [scribe assist by Manu Sporny]
: yes, moving forward this is what we'll be using.
: good work, it has sped up how quickly we can handle new things upcoming like payment intents, etc.
... hopefully we'll be able to implement new ideas more quickly.
... anything else on this before moving on? (nothing) ... so on to web keys.
Topic: Web Keys: Removing prefixes & context management
... we'll be talking about section 2 in the spec first.
... first we want to talk about if we want to do what we did with the payswarm spec with terms vs. prefixes/curies.
... i think we want to switch over to terms here as well.
... the other important thing to note is that if we go to a prefix-less mechanism we have to make sure that the payswarm context (JSON-LD) must contain the same terms defined in the web keys context
... the payswarm json-ld context would become a superset of the web keys context.
: yes, it's possible and we should move to terms.
David I. Lehn
: would the payswarm spec contain more than that?
: we were going to have a web keys vocab (and JSON-LD context)
: but instead the web keys spec will just use the security vocab
... and the payswarm context will import the security vocab and other vocabs (commerce), etc
... the payswarm context will grow considerably in size, but the trade off will be to make it easier json developers
... was there a concern there, dlehn?
David I. Lehn
: maybe just maintenance if the versions are changing at different rates, etc.
: what we did with rdfa was that whenever something was added to the context it couldn't be removed, and each context was versioned along with the spec
... so for example we have purl.org/payswarm/v1 as the json-ld context and webkey/v1 as the web keys version
... so on non-major versions you can add terms, but on major versions you could minimize things down and remove terms
... and that allows a decent forward compatibility way and add new terms in an ad-hoc way
... does that seem like a reasonable way to go forward?
David I. Lehn
: we should try it and see how it works
... is there an issue with terms that collide with other vocabularies?
: yes, we were concerned with that in the beginning but we haven't found anything yet
: we will rename terms if there is a collision
... for instance, title collided in the other community work we did, (title of a book, etc. title of a job), so we would use jobTitle or bookTitle instead, etc.
... we would just add more specific terms as needed, but there are no known conflicts with these vocabs at the moment
... in the future we should know there is a conflict right away and the keys will point at different IRIs
... the other thing we might need to do is put prefixes in there, so for web keys we might put wkey prefixes in there (in the context) just so you can use terms if you want to
... so you can use prefixed terms from various vocabs if you really want to, but the terms would be preferred.
... (non-prefixed terms)
... so i guess we're switching to terms and dropping prefixes (other than as optional).
... in the contexts we use.
: yes, that's the best course of action i think.
: so on to the key registration process...
Topic: Web Keys: Key Registration Process
: We currently use this URL for exposing the web key registration URL - /.well-known/linked-data-services
... there's a document on a server that supports web keys that tells any client application where the service end points are
: We might try switching to this - /.well-known/web-services
... we could change that to just web-services (instead of linked-data-services)
... because people may not understand what "linked-data-services" means
... the other concern is that the linked-data community might be confused because they don't publish linked data services in this way
: Make it specific like - /.well-known/web-keys ?
... the two options are make it very specific and say web-keys or if we believe that this is a pattern that the rest of the web is going to start using more heavily we could make it more general
: Make it more general - /.well-known/liked-data-services or /.well-known/web-services ?
: Suppose it is more popular - do we want just one endpoint where various APIs and services would share one file? [scribe assist by Manu Sporny]
David I. Lehn
: we probably should register what we use:
David I. Lehn
David I. Lehn
: it's cleaner to have a monolithic file, i think, but that isn't very webby
... here's the concern i have: for payswarm, we would have to have two different endpoints
... and two separate HTTP requests would have to be done if we take the more monolithic approach
... then there's a concern that you might start stomping on other services
... do we need to figure out how each application registers with that file?
: This needs some more thought and discussion before we try to make a decision. [scribe assist by Manu Sporny]
: If it's all in one monolithic place - sure we cut down on the number of HTTP requests - but how often does that happen. There is a concern that you might have spec fighting if you use one file. [scribe assist by Manu Sporny]
: I can see benefits and drawbacks for both... I'm not leaning toward either one. [scribe assist by Manu Sporny]
David I. Lehn
: i also don't have any strong feelings about it
: maybe we should ask the linked data community which way they think is a good approach
... i would expect that we get the document back as key-values in JSON-LD compacted form
: There is also stuff in there about whether we return relative URLs... [scribe assist by Manu Sporny]
: We may want to support different URL naming schemes that URLs have w/o making it too complex. For example - individual identities have public keys. Public keys exist as a path off of an identity... you have to construct the URL. Not everybody is going to want to use a query string to pass the correct information to get back the key. [scribe assist by Manu Sporny]
: well, the spec's URLs might just have to do with where you go to get a UI for registration for registering a key
(discussion about specifics of webkey registration, etc)
: I need to go back to see what other key services we expose in PaySwarm. [scribe assist by Manu Sporny]
: is there anything we need to change about the registration process?
: I'm pretty sure this is effectively what we have going on right now. [scribe assist by Manu Sporny]
Topic: Web Keys - Discovery
: we have a section in here on discovery
: when you register a key you get an IRI back for where the key is so you can get it back (i'm guessing v1 we'll just return JSON-LD)
... you get back other information about the key like the owner, revocation date and time, etc.
... you do a GET on the IRI and you get that information.
... we have a section on verifiable messaging
... we need to strip out prefixes, etc
... we have two forms of messages here, digital signatures and encrypted messages
Topic: Web Keys - Messaging
... a question about the messaging system is: where do we store the signatures?
... JSON-LD has an @graph property where we could store the graph information and then have the signature as an attribute of that graph
... but rdfa can't express that information.
... we can't express the signature in named graph form
... so what we have right now may be what the digital signature stuff may have to look like.
... there's an optional thing we could do is have a payswarm application go out to the web and try to discover a digital signature on an asset, that signature will have the asset (or whatever else is signed) as the subject
... what we could do in payswarm, we could translate the data and move the signature out of the data
... so that when we store the JSON-LD the signature would be on the graph itself and the name of the graph would be the asset
... and we'd move the signature property out
... or we'd keep things as they are and just have the signature be internal to the graph.
... and at least that way the rdfa and JSON-LD will express the same thing.
... the problem is that you have to extract the signature like we do now.
... if rdfa had a graph attribute it would be clear what to do, but it doesn't have one.
... so we have to figure out which side we want to come down on.
... sandro hawke of the rdf working group thought it was fairly elegant that you could express the digital signature using triples rather than needing quads
... and i thought that it was actually kind of hackish because it's a signature on the graph not on the asset.
: Well, given that RDFa can't really express this information right now, I think it would be more of a hack if PaySwarm applications move the property onto the graph instead of onto the asset itself. [scribe assist by Manu Sporny]
: The process for verifying a digital signature is to remove the signature, normalize the graph and then check it against the signature. Since we can't do it cleanly, from both a political and technological standpoint, we should keep it as is. We can just specify that the signature algorithm removes "sec:signature" and serializes the graph. [scribe assist by Manu Sporny]
: The best thing is to just remove one signature property and validate that... it's unfortunate that everything isn't in a state to use named graphs, but it doesn't sound like not everyone in the RDF community agrees with that approach. I don't think we want to start treating the data differently from other applications. [scribe assist by Manu Sporny]
David I. Lehn
David I. Lehn
: i think dlongley summarized it pretty well, i agree
: so we're not going to use @graph for the digital signature stuff.
... we may use it internally, we'll see.
... if rdfa were to gain a graph attribute, we would probably use it.
: if that's the direction that the community wants to go, if people agree, then sure - I think that's the correct direction, and if they go that way - we'll follow. [scribe assist by Manu Sporny]
: so the signature stays inside the object that is being signed
... so next up is the permission and access rights delegation
Topic: Web Keys - Permission and Access Rights Delegation
... i think this is out of scope for the spec.
... this is just a note that says that during key registration you can indicate that you allow a service to have certain rights.
Topic: Web Keys - Key Revocation and Expiration
... next is key revocation
... the revocationDate property allows a date to be set earlier than the expirationDate to revoke a key
... the spec doesn't say how the key revocation happens
... is it a digitally signed delete message?
... does the revocation need to be programmatic? or are we allowing the UI to deal with it?
: Do we need to be specific about this? [scribe assist by Manu Sporny]
: we do a fair bit of hand waving with rights management
... and we could do the same with key revocation, where the process is out of scope, but you must provide a mechanism for allowing keys to be revoked.
: it is probably sufficient to say how to check if a key is revoked, which we currently say in the spec.
: however, an application probably wants to be able to revoke a key when uninstalled
: so we might want to include a message for doing this.
... is that useful or do we not want to deal with it?
David I. Lehn
: there is an issue where if you include the revocation date in the message the server needs to ensure it isn't in the past, etc.
: we can't allow people to revoke keys in the past as they could invalidate financial transactions they performed
... so there's an argument that the revocation date can't be sent by the user.
: We should say that in the spec - how to do revocation. [scribe assist by Manu Sporny]
: It should probably be a POST since you're just updating the information for the key with a revocation date. [scribe assist by Manu Sporny]
: then we should probably just define a POST message in the spec for doing revocation
: ok, then we'll add something to the spec.
: any other concerns about the web keys spec?
... alright then, that's it for the call today.
Created by the
Web Payments Community Group
. Shared with love under a