- From: <msporny@digitalbazaar.com>
- Date: Wed, 23 Apr 2014 15:07:51 -0400
- To: Web Payments CG <public-webpayments@w3.org>
Thanks to Dave Longley for scribing this week! The minutes
for this week's Web Payments telecon are now available:
https://web-payments.org/minutes/2014-04-23/
Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).
----------------------------------------------------------------
Web Payments Community Group Telecon Minutes for 2014-04-23
Agenda:
http://lists.w3.org/Archives/Public/public-webpayments/2014Apr/0146.html
Topics:
1. Meetings in Silicon Valley Last Week
2. Internet Identity Workshop
3. Digest Class to Use ni:// URI Scheme
4. Range of Nonce
Chair:
Manu Sporny
Scribe:
Dave Longley
Present:
Dave Longley, Manu Sporny, Brent Shambaugh, David I. Lehn
Audio:
https://web-payments.org/minutes/2014-04-23/audio.ogg
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: http://manu.sporny.org/2014/credential-based-login/
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
Brent Shambaugh: http://www.internetidentityworkshop.com/
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:
https://www.w3.org/community/webpayments/wiki/CategorizedWebPaymentsUseCases
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:
http://www.w3.org/2013/10/payments/minutes/2014-03-25-s6/
Manu Sporny:
https://www.w3.org/community/webpayments/wiki/CategorizedWebPaymentsUseCases
Manu Sporny: http://manu.sporny.org/2014/credential-based-login/
Manu Sporny:
https://web-payments.org/specs/source/identity-credentials/
Manu Sporny: https://web-payments.org/join
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:
http://lists.w3.org/Archives/Public/public-webpayments/2014Apr/0135.html
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
Manu Sporny:
http://lists.w3.org/Archives/Public/public-webpayments/2014Apr/0014.html
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]
Received on Wednesday, 23 April 2014 19:08:15 UTC