Web Payments Community Group Telecon

Minutes for 2014-04-23

Dave Longley is scribing.
Manu Sporny: Any updates or changes to the agenda?
Brent Shambaugh: I may throw something in at the end about a conference (internet identity workshop)
Manu Sporny: Let's do that second on the agenda

Topic: Meetings in Silicon Valley Last Week

Manu Sporny: I was in Silicon Valley/bay area last week and met with a number of payments companies/large tech companies, to propose a way forward for the web payments work, overall the reception was quite positive. In general after the web payments workshop happened, a number of the orgs were concerned that there wasn't really any consensus/direction that the work should proceed in, a lot of the orgs with those positions hadn't participated in a w3c workshop, tons of use cases provided not clear which to work on, a basis for the discussion we had was the blog post and the discussion on the mailing list
Manu Sporny: We mostly discussed stuff in this blog post: http://manu.sporny.org/2014/dawn-of-web-payments/
Manu Sporny: The idea here is that there are three things that we could focus on identity, payment initiation, digital receipts... as we predicted last week, digital receipts are the least controversial, many of the people we spoke with thought that, we can definitely work on that, payment initiation was more of a toss up, meaning that people didn't seem to have an opinion on it, they though it would be fine to standardize, but they didn't know what it would look like, and after we introduced the topic to most of them they didn't have any strong feelings that we shouldn't do that
Manu Sporny: The third thing we discussed was identity, which was someway controversial, meaning that we had put forth a proposal (Identity Credentials)
Manu Sporny: The credential-based login mechanism was a proposal for something we could use for KYC, anti-money laundering, login on the web, reporting, etc. and specifically the IdC spec is set up so that it can integrate with mozilla persona, openID connect, or be its own login mechanism, some large corps said they'd have a problem with it competing with openID connect, and they wanted it to integrate nicely rather than provide another login mechanism, there were some orgs that did feel a more decentralized login mechanism on the web and openID connect was not the best approach but this was a minority opinion
Manu Sporny: So we're going to change tactics a bit to make sure we can get this working with OpenID Connect
Manu Sporny: We're still waiting on w3c to publish the workshop result, it should be at some point near the end of this week, and then we'll find out when the actual interest group will start up
Manu Sporny: Any questions?
None, group moves on.

Topic: Internet Identity Workshop

Manu Sporny: Could you give a quick run down out of what you hope to get out of the workshop?
Brent Shambaugh: I was working on the use cases and started getting concerned about the identity aspect. I was also talking with Doc Searls, who runs the Internet Identity Workshop.
Manu Sporny: This year they're focusing privacy, surveillance, as well as payments
Manu Sporny: If you can point them to Identity Credentials that would be good, with respect to payments and privacy, we're putting together use cases for payments+identity, and if people are interested in identity then they should be interested in the work the web payments CG is doing, especially since w3c is planning on launching further work
Manu Sporny: Brent, anything else you're thinking of doing there?
Brent Shambaugh: My view was to get a better understanding of what you're doing with identity and then talk about it there
Manu Sporny: Ok
Manu Sporny: Anything else on the internet identity workshop?
Brent Shambaugh: Is there anything in particular i should be saying? do you want something specific towards payments? or just plug something that sounds close
Manu Sporny: You might want to say "these are the use cases we have going into identity and web payments, is there anything else people feel we should address as the first iteration of this technology"
Manu Sporny: "This is the input we had from the web payments workshop w/respect to identity+payments, anything else to consider?"
Brent Shambaugh: So this is stuff from the wiki?
Manu Sporny: Yes
Brent Shambaugh: That's what i should bring to start the conversation?
Manu Sporny: I believe so, let me get a link from the wiki
Manu Sporny: Ideally, you would also have your stuff, you'd have the use cases you've been doing integrated into that document, but i don't know if that's going to be possible in time for IIW #18
Manu Sporny: If you could take those identity use cases in there and get some feedback, that would be great
Manu Sporny: And then ask if they have any other use cases we should consider for identity and web payments
Brent Shambaugh: Is there a best way to present this?
Manu Sporny: It's an unconference, so you'd have to propose a session, either find a session where people are talking about this stuff, or you'd have to present/write identity and payments up on the board and pick some time to discuss this stuff, all depends on how comfortable you feel with leading one of those sessions, if you're uncomfortable, you could join a session that seems like it would be related to payments/interested in payments and tell them that the web payments CG is working on this stuff and that we have to solve the identity problem for payments and we had a successful workshop on payments and more than likely there will be some work starting on payments in w3c shortly so we have to get people interested in solving identity on the web involved in that group, then give everyone the link to the web payments workshop the part on identity, give people a link to credential-based login on my blog, give people a link to the identity credentials spec, give people a link to the identity use cases on the wiki link (specifically identity portion)
Manu Sporny: We have a join link for the CG, give them that
Manu Sporny: You should share these links:
Manu Sporny: That's the stuff most pertinent to the identity folks that will be there, tell them that we're actively working on this problem and it is more than likely to end up in some kind of w3c work, if they want to have an impact, please join the group
Brent Shambaugh: Makes sense
Manu Sporny: They are fairly chaotic meetings, so you never really know what to expect, other than they do have payments listed there as something that is interesting to folks
Brent Shambaugh: Would leading a session there require me to be an expert or just have an interest?
Manu Sporny: The second, but you have to have a fairly structured agenda, like with how we run these calls we always have an agenda, if you want to lead a session, create an agenda and spend some time working on what you want to get out of it, then you say "these are the things we want to talk about, give a one paragraph overview" then hand it over to the group to discuss that
Brent Shambaugh: I don't want to dominate what they're doing, i just want to give exposure for what we're doing here.
Manu Sporny: Right, and the ideal way to do that is to have your own session, and say "for those interested in the overlap between identity and payments come to this session" and just say what the agenda will be
Manu Sporny: We can work with you on the agenda to make sure it's fairly clear
Brent Shambaugh: Happens may 6th-8th
Manu Sporny: Ok, we've got plenty of time, the next one after that is october, which overlaps w/ W3C TPAC in San Jose
Manu Sporny: Ok, we'll try and help you create an unconference session for the internet identity workshop, and then you'll try and run a session, sound good?
Brent Shambaugh: Yeah, sounds good
Manu Sporny: Thanks for going out there, that will be very helpful to get people knowledgeable about the work going on here

Topic: Digest Class to Use ni:// URI Scheme

Manu Sporny: Melvin suggested switching to the RFC 6920 for digests
Manu Sporny: There's a well known URL scheme for digest URLs
Manu Sporny: For example - ni:///sha-256-32;f4OxZQ?ct=text/plain
Manu Sporny: Should we switch to that? What we have right now looks like this:
Manu Sporny: {
Manu Sporny: "@Context": "https://w3id.org/security/v1",
Manu Sporny: "@Type": "Digest",
Manu Sporny: "DigestAlgorithm": "http://www.w3.org/2000/09/xmldsig#sha1",
Manu Sporny: "DigestValue": "981ec496092bf6ee18d6255d96069b528633268b"
Manu Sporny: }
Dave Longley: I think this might end up being more difficult for web developers to use if they try to integrate w/ that RFC, doing microprocessing of the URL might be less developer friendly. [scribe assist by Manu Sporny]
Dave Longley: Maybe we could just include the ID and those properties about that ID. You could use either approach. If you use RFC6920, the author could include that as the identifier for the digest... but they could also include the digest algorithm and value. [scribe assist by Manu Sporny]
Manu Sporny: So, you're saying that we could have something like this: "@id": "ni:///sha-256-32;f4OxZQ?ct=text/plain" ?
Dave Longley: If you try to dereference that URL, what sort of Linked Data you get back. [scribe assist by Manu Sporny]
Dave Longley: Obviously, you want to get back JSON-LD that had some information. Maybe we want another property in there, the niUrl property? It might be incorrect to have the "@id" be the ni:/// URL. [scribe assist by Manu Sporny]
David I. Lehn: Parsing microsyntaxes is annoying, if you need to do it. It's a general URL, so you could probably use a general URL processor. [scribe assist by Manu Sporny]
David I. Lehn: No strong opinion, there are some places where we're using URIs that are useful, don't know if this is one of those cases. [scribe assist by Manu Sporny]
Dave Longley: It may make certain querying cases more difficult, if you're not using a direct HTTP dereference, it's strange. [scribe assist by Manu Sporny]
David I. Lehn: Could you elaborate? [scribe assist by Manu Sporny]
Dave Longley: If you want to get a digest value, you want to frame the data out in a way to get the digest value out - it becomes difficult to do, you're looking for very specific URLs. We don't know enough about this RFC to make an informed enough decision at this point, but I'm skeptical of it making things easier. I can see how having that information would be helpful for people using RFC6920, we could just add something for now. [scribe assist by Manu Sporny]
Dave Longley: It becomes something new that you have to write new code for, rather than just extracting the value and checking it against the value. You have to understand how to parse the ni: URI schemes, how to communicate with it, etc. There's more stuff you have to do with it all of a sudden. [scribe assist by Manu Sporny]
David I. Lehn: Don't know if it's normalized to some form or not... don't know if the URL string is normalized, if it is, it's useful for using it as an index. Use it as a unique key. [scribe assist by Manu Sporny]
Dave Longley: The purpose of the RFC is to create a way to identify a particular thing using a hash, you'd be identifying the digest object as a thing, vs. what the digest is a digest for. If you had a document that had a digest property in it... hmm, thinking. [scribe assist by Manu Sporny]
Dave Longley: The way the spec is written, it seems like you'd change the IRI to be the hash for the document, it's not that the digest object attached to the graph would have the identifier. It doesn't seem like the modelling is correct, changing the identifier would also mess up the signature mechanism. If you change the identifier, it would change the graph. The identifier itself is a part of the hash of the document. There's a self-referencing problem that exists if we use the spec in the way it's intended. We're not looking to name the digest object, we're trying to name the document itself. The modeling seems broken. [scribe assist by Manu Sporny]
Manu Sporny: We need to talk to Melvin about this more. [scribe assist by Manu Sporny]
Dave Longley: It might be good to use this as a part of the information about the document, you're signing a particular graph at a point of time/history. This URL identifies that graph. It might be useful for signed named graphs... you could use RFC-6920 to assign a name to named graphs, we didn't have a way to do this before. Now we might be able to use this. [scribe assist by Manu Sporny]
Dave Longley: So, if you wanted to, you could name the graph using the ni:// scheme... so the name is the hash, the hash is the hash on the actual document that's signed. [scribe assist by Manu Sporny]
Manu Sporny: So, the graph name would become "@id": "ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q"
Manu Sporny: Is the .well-known scheme useful in RFC6920?
Dave Longley: Not really, since JSON-LD just uses the URL for the information... you don't need a ni:// scheme. The only place it's useful is when you don't have a Linked Data system. If you have a Linked Data system, you don't need the .well-known mechanism. [scribe assist by Manu Sporny]
Dave Longley: I don't know how useful that is to do. If everyone is using Linked Data, there is no need for .well-known. In order to use that, you need to know the authority URL. There is no purpose for having well known. [scribe assist by Manu Sporny]
Manu Sporny: So, what's the final thing that we think? [scribe assist by Manu Sporny]
Dave Longley: What does this mechanism bring to the table? If it passes that test, should we use it to replace what we have? [scribe assist by Manu Sporny]
Dave Longley: It doesn't seem like it integrates well with Linked Data, it seems like it's a parallel (inferior) mechanism. It could have use for named graphs. [scribe assist by Manu Sporny]

Topic: Range of Nonce

Dave Longley: When you have code in an app, there is a context - it's deterministic in the code that you're writing. You would know, implicitly, how nonce is used because your context says so. [scribe assist by Manu Sporny]
Dave Longley: It might get a little more complicated if your type information in the context doesn't match up. [scribe assist by Manu Sporny]
David I. Lehn: This seems like it would make it more complicated to have multiple allowable ranges. [scribe assist by Manu Sporny]
Dave Longley: Ultimately, whatever you're communicating with, for the majority of apps, you're going to be using nonce in only one way. You can put the nonce into a context for your application and things will work properly unless they've messed up the data. [scribe assist by Manu Sporny]
Dave Longley: If you have a complex app that could use strings, base64, or hexBinary, your code will have to become more complex to deal with the problem. [scribe assist by Manu Sporny]
Dave Longley: If we open up the range, we have to do that. I believe that we have a signatureValue property that we have, and I think that's just an xsd:string. In the Secure Messaging spec, we say that the string is a base64-encoded string. We specify what it should be in the spec. Your spec can say what the encoding should be for signature values, so the code doesn't have to deal w/ other applications that have nothing to do w/ what you're trying to do. [scribe assist by Manu Sporny]
Dave Longley: If you include the encoding information in the vocabulary, then every application gets more complex. If you include the value in the specification, then only the applications that need to interoperate care. [scribe assist by Manu Sporny]
Dave Longley: So the tradeoff is - put all the information in the Linked Data and make processing more complex, but generalized. [scribe assist by Manu Sporny]
Dave Longley: Or, you put the information in the spec, and make applications easier to write, but now the application needs to understand the spec as well. [scribe assist by Manu Sporny]
Manu Sporny: I don't think we want to head towards a future where the app needs to understand a spec to be able to decode binary values. [scribe assist by Manu Sporny]
Dave Longley: There is a certain amount of leakage into legacy applications for JSON-LD values. Everything we've designed to this point, you could always view as JSON. This means that the developer might see strange xsd: values. [scribe assist by Manu Sporny]
David I. Lehn: URL-safe mechanism? [scribe assist by Manu Sporny]
Dave Longley: We have to make sure the xsd: one uses the correct encoding. [scribe assist by Manu Sporny]
Manu Sporny: Ok, so the proposal is to support xsd:base64Binary and xsd:hexBinary - do not use xsd:string because you have no idea what the encoding is. [scribe assist by Manu Sporny]
Dave Longley: Xsd:base64Binary is not URL-safe. [scribe assist by Manu Sporny]
Dave Longley: Let's just do hexBinary for the nonce. For the signature, we will probably use xsd:base64Binary. [scribe assist by Manu Sporny]
Dave Longley: Non-URL safe. [scribe assist by Manu Sporny]

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