Web Payments Telecon Minutes for 2012-06-12

Thanks to Dave Longley for scribing! The minutes for today's telecon are
available here:

http://payswarm.com/minutes/2012-06-12/

Full text of the discussion follows for archival purposes at the W3C.
Audio of the meeting is available as well (link provided below).

--------------

Web Payments Community Group Telecon Minutes for 2012-06-12

Agenda:
   http://lists.w3.org/Archives/Public/public-webpayments/2012Jun/0001.html
Topics:
   1. Updates to the PaySwarm implementation
   2. Web Keys - Removing prefixes & context management
   3. Web Keys - Key Registration Process
   4. Web Keys - Discovery
   5. Web Keys - Messaging
   6. Web Keys - Permission and Access Rights Delegation
   7. Web Keys - Key Revocation and Expiration
Chair:
   Manu Sporny
Scribe:
   Dave Longley
Present:
   Dave Longley, Manu Sporny, David I. Lehn
Audio:
   http://payswarm.com/minutes/2012-06-12/audio.ogg

Dave Longley is scribing.
Manu Sporny:  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

Manu Sporny:  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?
Dave Longley:  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]
Dave Longley:  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]
Dave Longley:  It was fairly slow going when developing with C++
   and MySQL... so we wanted to switch to something that's more
   flexible. Easier to integrate technologies and scale out with
   JavaScript and MongoDB. [scribe assist by Manu Sporny]
Dave Longley:  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]
Dave Longley:  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]
Manu Sporny:  ok, thanks for the overview, for the near future we
   plan on using this code/technology stack?
Dave Longley:  This was mostly about accelerating development
   speed and ease of implementation. [scribe assist by Manu Sporny]
Dave Longley:  yes, moving forward this is what we'll be using.
Manu Sporny:  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

Manu Sporny: http://payswarm.com/specs/source/web-keys/
   ... 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.
Dave Longley:  yes, it's possible and we should move to terms.
David I. Lehn:  would the payswarm spec contain more than that?
Manu Sporny:  yes
Manu Sporny:  we were going to have a web keys vocab (and JSON-LD
   context)
Manu Sporny:  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.
Manu Sporny:  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?
Manu Sporny:  yes, we were concerned with that in the beginning
   but we haven't found anything yet
Manu Sporny:  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.
Dave Longley:  yes, that's the best course of action i think.
Manu Sporny:  so on to the key registration process...

Topic: Web Keys: Key Registration Process

Manu Sporny:
   http://payswarm.com/specs/source/web-keys/#the-key-registration-process
Manu Sporny: 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
Manu Sporny: 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
Manu Sporny: 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
Manu Sporny: Make it more general -
   /.well-known/liked-data-services or /.well-known/web-services ?
Dave Longley:  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: http://tools.ietf.org/html/rfc5785#section-5.1
David I. Lehn:
   http://www.iana.org/assignments/well-known-uris/well-known-uris.xml
Manu Sporny:  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?
Dave Longley:  This needs some more thought and discussion before
   we try to make a decision. [scribe assist by Manu Sporny]
Dave Longley:  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]
Dave Longley:  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
Manu Sporny:  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
Dave Longley:  There is also stuff in there about whether we
   return relative URLs... [scribe assist by Manu Sporny]
Dave Longley:  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]
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)
Dave Longley:  I need to go back to see what other key services
   we expose in PaySwarm. [scribe assist by Manu Sporny]
Manu Sporny:  is there anything we need to change about the
   registration process?
Dave Longley:  I'm pretty sure this is effectively what we have
   going on right now. [scribe assist by Manu Sporny]

Topic: Web Keys - Discovery

Manu Sporny:  we have a section in here on discovery
Manu Sporny:  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.
   ... thoughtS?
Dave Longley:  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]
Dave Longley:  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]
Dave Longley:  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:  thoughts?
David I. Lehn:  i think dlongley summarized it pretty well, i
   agree
Manu Sporny:  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.
Dave Longley:  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]
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.
Manu Sporny:

http://payswarm.com/specs/source/web-keys/#permission-and-access-rights-delegation
   ... 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?
Dave Longley:  Do we need to be specific about this? [scribe
   assist by Manu Sporny]
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.
Dave Longley:  it is probably sufficient to say how to check if a
   key is revoked, which we currently say in the spec.
Manu Sporny:  however, an application probably wants to be able
   to revoke a key when uninstalled
Manu Sporny:  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.
Manu Sporny:  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.
Dave Longley:  We should say that in the spec - how to do
   revocation. [scribe assist by Manu Sporny]
Dave Longley:  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]
Dave Longley:  then we should probably just define a POST message
   in the spec for doing revocation
Manu Sporny:  ok, then we'll add something to the spec.
Manu Sporny:  any other concerns about the web keys spec?
   ... alright then, that's it for the call today.

-- 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, 12 June 2012 19:23:57 UTC