- From: <msporny@digitalbazaar.com>
- Date: Wed, 05 Mar 2014 13:51:59 -0500
- 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-03-05/
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-03-05
Agenda:
http://lists.w3.org/Archives/Public/public-webpayments/2014Mar/0024.html
Topics:
1. Web Payments Mobile Use Cases
2. Persona and Web Identity Spec
3. Decentralized Credentials-based Login
4. HTTP Signatures
Chair:
Manu Sporny
Scribe:
Dave Longley
Present:
Dave Longley, Natasha Rooney, Manu Sporny, Erik Anderson, David
I. Lehn, Brent Shambaugh
Audio:
https://web-payments.org/minutes/2014-03-05/audio.ogg
Dave Longley is scribing.
Topic: Web Payments Mobile Use Cases
Manu Sporny: https://github.com/w3c-webmob/payments-use-cases
Natasha Rooney: Hi Natasha from GSM Association, big mobile
standardization organization, Brent has offered to help out on
mobile payments use cases, what we're doing is taking use cases
for how payments exist on native platforms, possibly in
proprietary solutions on the web, and documenting how they work
on mobile
Natasha Rooney:
https://www.w3.org/community/webpayments/wiki/WebPaymentsMobileUseCases
Natasha Rooney: Thx for putting up link to github page, there's
also a wiki, the work is in two places, i'd like to move both
into github, my preference
Natasha Rooney: Or continue to work on the wiki, the issue there
is that the mobile access group doesn't have access to the wiki
Manu Sporny: The wiki was meant to be temporary, we didn't want
20-30 PRs out there conflicting, we wanted a rapid way to dump
information in there, and then organize and move back to github
Manu Sporny: If you feel there's enough information there please
pull it back into github
Manu Sporny: There are some outstanding questinos there we'll
get to later
Manu Sporny: We wanted to be able to iterate on it quickly and
github PR was maybe going to slow it down
Natasha Rooney: Makes perfect sense, i'll pull things into
github repo
Natasha Rooney: https://github.com/w3c-webmob/payments-use-cases
Natasha Rooney: I went through the wiki style use cases, got
criticized by co-chair saying we really should document solutions
that exist across native platforms, and that experience on
mobile, if you scroll down to the paypal section on github,
there's an example of what i'd like to produce for all of the
other native applications/plugins/proprietary apps
Natasha Rooney: I've put in regions where it operates,
capabilities, APIs to develop
Natasha Rooney: I consider API very interesting as something we
could use as a standardization body to create an API later on,
not wanting to get into a legal discussion now there are legal
issues, just a good guideline
Natasha Rooney: We'd like help from both this group and the rest
of the mobile interest group as well, we want a robust set of use
cases for payments for mobile
Natasha Rooney: Manu you mentioned questions?
Manu Sporny: I think you answered a good chunk of them, the main
thing we were concerned about -- some of the use cases weren't
use cases but feature sets, some people disagree on what "use
case" means.. don't want to get bogged down there... so we've
been taking any use cases we can see from websites for payment
providers and also pulling any features that seem important but
can't be categorized as use cases and documenting those too. Your
developer API sections make more sense to me now, might be
difficult to get all that information together before W3C Web
Payments Workshop.
Manu Sporny: The high-level question is .... it's confusing how
we should categorize mobile payments use cases vs. just web
payments use cases, because as you said there's a lot of overlap,
so in general we've been trying to capture everything and then we
can pull the mobile bits out of everything, the reason for
capturing everything is that we dont' have a document outlining
all the payment systems out on the web today so this would be a
good opportunity to do that, and at the same time we'd get the
mobile use cases
Manu Sporny: In particular did you have a way that you wanted to
classify the mobile payments stuff? What qualifies a mobile
payments system
Natasha Rooney: I was taking the approach of everything as well,
focusing on everything means there's a lot of work to do, but not
focusing on it and thinking just focusing on the desktop issue
may cause issues later on, think of this instead as a
data-gathering exercise and then from that data identify the use
cases, so when i looked at google wallet and paypal there was a
common set of use cases
Natasha Rooney: So i think one doc for data and then have
another doc that identifies use cases and put data underneath it
would work
Manu Sporny: Yeah, my concern is getting something to the web
payments workshop that's useful, i feel we have a decent chunk of
work in front of us that could be reduced by just doing a fairly
high-level pass of these systems
Manu Sporny: We still capture a good chunk of common use cases
Manu Sporny: For example, being able to pay with a digital
wallet that supports credit card and bank account
Manu Sporny: We have a lot of these payment mechanisms out there
on this web payments mobile use cases page, but if we do just a
really quick scan across the site, 10-15 minutes per platform we
can get a good high-level summary of the types of features that
there are, we won't be able to get deep into development API, but
we can get what each site thinks are the most important features
that they provide, that way we can get this done in the next week
hopefully and then there's a week left to get things down to
something the workshop can use
Natasha Rooney: Makes sense i can find key cases that exist
between them
Natasha Rooney: I forget how close it is to the workshop
Natasha Rooney: After this call, i'll do that email to both
groups about what we're going to do now and hopefully we'll get
some people to help brent and me out here
Natasha Rooney: Feel free to raise an issue on the github repo,
if you have a particular thought, don't feel you'll have to deal
with it, if you're silent we won't know about it, please be vocal
Manu Sporny: Let's say the deliverable to the workshop is the
first iteration of the use cases, after that the CG will want to
go back in an expand out each of the high level things, we'll
want to do a deep dive into dev APIs for types of calls they
provide, things like that, do you want to coordinate through the
payment use cases thing throuhg the web and mobile group or do
this somewhere else? seems this will turn into a living doc on
all the payment systems out there, i'm happy to put it in the
payments use cases repo, if you think that's something the web
and mobile group would be interested in to collaborate on.
Natasha Rooney: Yeah, i think you guys should eventually pull it
in, it can stay where it is now, but you guys can pull it over
later it would be best
Natasha Rooney: We can still work on this with you guys of
course, you can always get me to join a call, we can have that
discussion about what other work needs to be done
Manu Sporny: The rough plan then is to get as many people as we
can get to keep fill out the use cases wiki, preferably following
the format of the paypal example in the github repo (payments use
cases repo) and once we're done filling that out, you (Natasha)
will pull the pieces you think are applicable to mobile payments
into the github repo and do some editing there, and whatever that
doc ends up becoming it's one we will provide to the web payments
workshop
Manu Sporny: After the workshop, we'll figure out a way of more
properly getting all the information together and maybe we'll put
it into a respec format or github repo or something and continue
to add deeper info about dev APIs and other things that aren't
quite apparent at first glance from lookign at this websites,
that sound good?
Natasha Rooney: Absolutely perfect, you've got it all
Erik Anderson: No input from me, all good discussion
Natasha Rooney: I have to run, but it sounds good
Topic: Persona and Web Identity Spec
Manu Sporny: https://web-payments.org/specs/source/web-identity/
Manu Sporny: The spec's been worked on for a while now, the spec
covers ways to identify people, home address, KYC, email, payment
systems and banks need this info, the web identity spec defines a
mechanism for storing that info and retrieving it in a
decentralized way
Manu Sporny: When you log into a website you can provide your
home address, credit score, govt ID, etc. in a way that's
digitally signed, your govt ID for example could be signed by
your national govt and your bank could depend on it
Erik Anderson: I have a call with the Department of State later
on this week concerning this subject
Manu Sporny: We're also working with an entity in the education
arena and they have millions of identities that they have to
identify on a yearly basis... they have to ensure people have
university degrees, make sure people have credentials to do
surgery on people, practice medicine as a nurse, things of that
nature.
Manu Sporny: This is cryptographically verifiable identity
stuff, where it really matters if that doctor that is going to
operate on you is qualified, or that multi-thousand dollar
transaction you're going to do is actually approved by you, etc.
Manu Sporny: We've been operating with this name "Web Identity"
for a while now which is confusing because there are other
identity specs out there, this spec is more about verifiable
credentials
Manu Sporny: The idea to rename the spec to "identity
credentials" or "web credentials" or "entity credentials" has
been floated
Manu Sporny: The idea here is to help people understand that
while identity is an aspect of this it has more to do with
verifiable credentials than not
Manu Sporny: I think the current proposal is "web credentials"
or "identity credentials"
Erik Anderson: "Digital credentials" works too
Manu Sporny: Stephen rowat pointed out that "web" isn't that
useful in the name
Manu Sporny: "Digital" is sort of like "web" here, doesn't add
all that much
Dave Longley: I agree that "identity credentials" is better.
[scribe assist by Manu Sporny]
Erik Anderson: "Identity credentials" ... people want to be
anonymous on the web, could bring library of congress in - lots
of people do identity, you want to show up well on searches.
Erik Anderson: Might be hard to find (too generic)
Manu Sporny: We do want the name of the spec to be fairly unique
Manu Sporny: "Digital credentialing" is pretty well-used term as
well
Dave Longley: "Decentralized Credentials" ?
Erik Anderson: I like that, it's ok
Manu Sporny: Yeah, that's ok
Erik Anderson: I have to drop off, another call
Manu Sporny: We'll send the new name to the mailing list to see
if anyone objects
Manu Sporny: We had some spec changes, most recent change is the
login mechanism that was just added
Topic: Decentralized Credentials-based Login
Manu Sporny: A commit was made yesterday to the "Decentralized
Credentials" specification adding a Persona-like login mechanism:
https://github.com/web-payments/web-payments.org/commit/e88f5717bb0a1496289bfae17312cfda34bdb468
Manu Sporny: The section can be viewed here:
https://web-payments.org/specs/source/web-identity/#web-credential-based-login
Manu Sporny: The spec provides a way to assert facts about
yourself, the same mechanism can be used for login, now that
persona is on the backburner at mozilla, we're back to not really
having a unified login mechanism other than OpenID connect, and
while we could use Decentralized-Credentials-based login using
OpenID connect, the flow is not ideal, the other issue with
OpenID connect is that there are something like 17 specs you need
to implement to get it working, it's not trivial to implement to
do a login. Persona by comparison was fairly trivial to
implement, especially if using secure messaging instead of the
JOSE stack.
Manu Sporny: So what was added to DC spec was an example of
login mechanism, so if you don't have openID or persona then you
can still do a login, it's a fairly simple 2-step process
Manu Sporny: The other thing that this new login flow does is
... it can operate as a replacement for persona, it's a much more
simplified version for persona, it also means there can be a
browser polyfill for it, using a regular desktop, tablet, etc you
can do an email-based login
Manu Sporny: Looks like this: customer goes to a store to make a
purchase, type in/auto fill email, and if they have the browser
implementation then they'll log right in. If they don't, then the
polyfill will contact a 3rd party identity login service that
looks just like Persona.
Manu Sporny: It's a fairly nice way of doing login, with one
exception in that 3rd party app could find your ID using a
decentralized protocol
Manu Sporny: We're looking at using telehash for the
decentralized bits of it.
Manu Sporny: So all the identity providers don't have to be tied
to a single third party
Manu Sporny: They just join a decentralized network
Manu Sporny: If you dont' have browser impl. then 3rd party
network finds your ID provider and store talks to them and gets
digitally signed ID+email (that credential)
Manu Sporny: Your credential could be stored on a completely
different identity provider, etc. it's fairly complicated behind
the scenes but the customer it just is a quick login with browser
support or not.
Manu Sporny: What the store gets is a digitally-signed assertion
that you have that email address, which is what persona does
right now.
Manu Sporny: Since we're also talking about payments here, what
we also want is to send your preferred payment provider to the
store, so the credential will include verified email and payment
provider
Manu Sporny: Other things in the future could include, email
address, preferred payment provider, and shipping address when
logging into amazon, for instance, etc
Manu Sporny: Dave Longley, we may want to talk a bit more about
the telehash-based mechanism
David I. Lehn: Why are we considering telehash?
Dave Longley: At a high-level the telehash based mechanism -
decentralized network - makes it easy to discover nodes on a
decentralized network. Individual identity providers would
generate a hash and join a network. Any queries that came across
the network for various credentials would return which identity
provider could provide the credentials. We want an authentication
layer on top of this. [scribe assist by Manu Sporny]
Dave Longley: We need to think through the authentication layer
a bit more. Basic idea is that authenticated requests for given
email address. Other credentials could be used. Decentralized
network would respond w/ which identity provider handles which
email address. [scribe assist by Manu Sporny]
Dave Longley: If you have a browser implementation, it provides
the login information directly. If you don't have a browser
implementation, you ask the decentralized network. [scribe assist
by Manu Sporny]
Manu Sporny: So, in general, you go to the store and put in your
email address. That store calls
navigator.id.login('email@example.org',
'http://example.com/login-callback'). In the browser-native
implementation, that would create a dialog where the user picks
which identity they want to use to login, the email credential
verifying that you own the email address is retrieved from the
identity provider, and the credential is delivered to the
website.
Manu Sporny: In the non-browser-native implementation, the
polyfill would open a browser window to a trusted, open source
login aggregation site (jointly run by W3C, Mozilla, and IETF).
That site would hook into the telehash protocol, retrieve your
email-to-identity-provider mapping (protected via a password to
prevent information leakage), and use that to map the email to
the identity provider. The rest of the interaction would be the
same as the browser-based mechanism above. Note that this step is
done to ensure that the identity provider doesn't know where
you're using each credential (tracking protection).
Dave Longley: We might be able to implement this where the store
would just have a javascript telehash client, which just runs in
your browser. Browser connects and gets your identity provider.
[scribe assist by Manu Sporny]
Manu Sporny: There are of course, privacy issues w/ that
approach - namely that each store would know who your identity
providers are (and that's probably not a good thing).
Dave Longley: Since the telehash client is a javascript client,
you can talk more closely with the browser. Maybe there is
something clever we can do w/ the authentication there -
leveraging Web Crypto for one-time pads. The information that you
use is only in localstorage for that site. There are some
implementation details that we need to think through, but that we
can use a javascript telehash client means that we may be able to
solve the privacy issues as well. [scribe assist by Manu Sporny]
Manu Sporny: We can always fall back to a 3rd party site to do
the implementation, like Persona did.
Dave Longley: It is fully decentralized, but we provide a
mechanism to ease implementation. [scribe assist by Manu Sporny]
Manu Sporny: We don't want identity providers to be able to
track you across the web, there's a debate about whether or not
that's ever possible, etc. evercookies, google tracking, etc.
Manu Sporny: However, that's another concern and we'll get to
that in time. The solution is simpler than OpenID Connect and
requires less of a technology stack (and infrastructure) than
Persona.
Topic: HTTP Signatures
Manu Sporny:
https://web-payments.org/specs/source/http-signatures/
Manu Sporny: We've gotten good feedback from some folks working
on HTTP/2 and HTTPbis
Manu Sporny: We've made updates based on mark nottingham and
julian reschke's feedback
Dave Longley: We should also make sure to review this (looks
more or less like what we ended up with):
http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html
Dave Longley: And this, which was abandoned:
https://tools.ietf.org/html/draft-burke-content-signature-00
Manu Sporny: The other thing that's interesting with the
signature stuff is that the Authorization header that is meant to
be client-server, http is written such that the client and server
can switch places, and that's perfectly fine, the problem is in
including Authorization header in an http response
Dave Longley: I believe that Content-Signature might not be the
right thing... maybe just "Signature" header? [scribe assist by
Manu Sporny]
Manu Sporny: If we do that, should we have the Authorization
header? [scribe assist by Manu Sporny]
Dave Longley: If we do that, we should abandon Authorization, or
put it in another specification. [scribe assist by Manu Sporny]
Dave Longley: Maybe Authorization should be for sessions only?
[scribe assist by Manu Sporny]
Manu Sporny: Maybe we'll put Authorization into a different
spec, and Signature header into a different spec? Authorization
builds off HTTP Signature Header spec? [scribe assist by Manu
Sporny]
Dave Longley: That allows us to make a number of changes w/o
breaking backwards compatibility. [scribe assist by Manu Sporny]
Dave Longley: If they're just using the Signature header,
they're using the new mechanism. If they're using it in the old
way, it either won't function or it won't be supported. [scribe
assist by Manu Sporny]
Brent Shambaugh: Sorry that I did not make it to the beginning
part of the teleconference. Did it go well?
Brent Shambaugh: I just posted thoughts to the list. It might be
better there.
Manu Sporny: Yeah, posting to the mailing list is helpful,
thanks.
Received on Wednesday, 5 March 2014 18:52:22 UTC