Re: Proof of Concept: Identity Credentials Login

At Accreditrust, we are specifically interested in the Identity
Credentials spec
and this particular way of doing things.  Accreditrust is addressing the
need for associating secure credentials to a long-lived identity URL
through its TrueCred(TM) Open Credentialing Platform.

We see identity-based credentials to be a critical element of web-payments.
 We haven't found a situation where an applicant isn't asked to provide a
form of identity to establish an account with a financial institution.
(Companies like Experian make millions providing this kind of check!) By
issuing a digitally signed credentials to an identity ("identity-based
credentials") such as a driver license, passport, or federal identification
number, a website could simply request the credentials from the web
identity.

Once the identity is established, it makes sense to curate other
high-stakes credentials with it. By way of example, suppose someone was
applying to a college or take a required skills test.  Once the applicant
is authenticated with their identity provider, the registration website
could retrieve the required credentials such as their driver's license data
(address, state, zip), health card, citizenship, transcripts,
professional licenses
and form of payment to pay the application fees.

It only makes sense that the Web Payments solution address a methodology
for interoperating with identity-based credentials.

Eric Korb
CEO, Accreditrust.com


On Wed, Jun 25, 2014 at 10:10 PM, Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 06/24/2014 07:03 AM, Adrian Hope-Bailie wrote:
> > As a general comment, great to see that I'm not crazy and as a whole we
> > are in agreement!
>
> Just because the group agrees doesn't mean we're not crazy. :P
>
> > Great! I see this as fundamental, push payments is the only way we can
> > ultimately migrate to a system where payments are initiated and
> > concluded on the Web (even if they are processed, cleared and settled
> > out of band).
>
> +1
>
> >     I think you're jumping in /after/ we had already come to the
> conclusion
> >     that 'push payments' were the way forward. We came to this conclusion
> >     around 3-4 years ago, so you're probably not going to get much
> pushback
> >     on that part of your idea. :)
> >
> > Again, yay!
> > That said, I haven't noticed it as prominently as I would expect in the
> > specs I have read on webpayments.org <http://webpayments.org>.
>
> Unfortunately, the specs are half-baked, poorly written, and not up to
> date with current thinking. They don't quite reflect where we are as a
> group due to lack of time to update the specs.
>
> > My experience in dealing with payments industry stakeholders is that
> > they have gotten so used to cards as the only way to do B2C payments
> > that they haven't even considered alternatives.
>
> For some stakeholders that's true, for others not so much. We've found
> that many know about the alternatives, but think that implementation of
> those alternatives are at least a decade or two off (this tends to be
> the common line wrt. most banks, large and small, that I've spoken with
> over the years).
>
> > If what we are doing presupposes that we will use a push payments model,
> > why so much focus on protecting the payer's identity?
> > As I have said before, sharing the payer's identity or proving some
> > payer credential is an edge case.
>
> Sharing an email address and shipping information is not an edge case.
> Those two pieces of information are regularly exchanged as a part of an
> online payment.
>
> > I see this standard as a means to use the internet to change existing
> > payments, most of which occur in the real world, not online.
>
> That could be one thing that the standard affects, yes. That said, we
> can't make that our solitary focus. If we're successful, we won't have
> to make a distinction between online and offline payments, or mobile and
> non-mobile payments. We're creating a set of modern standards for
> payments, full stop.
>
> > i.e. People are already making card payments at a POS today, how can we
> > change this so they use their mobile but not in a way that simply puts
> > their card on their mobile?
>
> +1, that's exactly the right question to ask (and one of the questions
> that we're attempting to address in this group).
>
> > My impression is that the work of the group thus far has been to take an
> > Internet payments first approach and that pulling in "brick 'n mortar"
> > use cases is a something that came after.
> > i.e. CNP eCommerce sucks, how can we make it better?
> > Am I wrong?
>
> No, we want the solution to work on the Internet and Brick and Mortar
> (BaM) as well. The issue with leading with Brick and Mortar first is
> that the BaM industry moves at a snails pace and the cost of upgrading
> POS terminals are quite large. There are large players (like Verifone,
> for example) in that industry that control access to what technologies
> are used and when they're deployed. We can't deploy and iterate quickly
> in BaM, but we can deploy and iterate quickly on the Web.
>
> > I see both as valid problems to solve but I see the brick 'n mortar
> > scenario as the one that should be solved first.
> > If you can solve that, entirely online payments can be solved easily.
>
> I strongly disagree. Why do you think it'll be easier to deploy in a BaM
> environment than an online one? Retailers are among the most
> conservative when it comes to new payment rails.
>
> > The payments process should a be simple one.
> > 1. Establish who is paying who and how.
> > 2. Process the payment
> > 3. Provide both parties with proof of the completed payment
> >
> > Other services like verifying the age of the payer, getting the shipping
> > address of the payer, generating a full invoice including the basket of
> > goods can all be bolted-on.
> > If we try to make them integral to the payment process then things get
> > way too complicated.
>
> I understand the point you're making, but I see your proposal as just
> digitizing the current payment flow we have today and paying with an
> electronic cheque equivalent.
>
> Keep in mind that there is nothing preventing organizations from simply
> doing what you state above with the current spec. You're talking about a
> simple transfer of money w/ a memo field (an electronic cheque). That's
> the easy problem to solve, and that what this spec is for:
>
> https://web-payments.org/specs/source/web-payments#the-transaction-process
>
> That approach also ignores much of the input that we've gotten from
> large retailers, banks, and governments. The fact is that identity is a
> big problem on the Web and in payments. The use case that you want to
> solve is just a minor part of the bigger problems with payments on the
> Web. You may want to review the input we got from major banks/retailers
> and financial technology companies here:
>
> http://www.w3.org/2013/10/payments/final_report.html#output
>
> This may also help:
>
> http://www.w3.org/2013/10/payments/minutes/
>
> While I agree that what you're proposing we do is a good first cut, it
> won't address the many other concerns that the world wide payments
> community has. Again, this is about striking a balance between boiling
> the oceans and spec'ing a toy payments protocol. If we go too far in
> either direction, adoption will fail. I expect that we'll be debating
> whether we're straying too far in either direction for the duration of
> the work we do here. :)
>
> > As far as I know real-time ACH is not possible in the US.
>
> It is, it's called FedWire, but it's only accessible to the banks. :)
>
> > To make a real-time payment you have to use a card.
>
> A card payment isn't real-time, the money can still take days to settle.
>
> ... but I get what you're saying. We want instantaneous
> customer-to-customer clearing. That said, what you've proposed doesn't
> lead to instantaneous customer-to-customer clearing.
>
> The banks have been able to do instantaneous customer-to-customer
> clearing for years now. However, when the time comes to vote for
> instantaneous customer-to-customer clearing, it's voted down each and
> every time because if it's allowed, the float goes away and banks lose
> that revenue stream on which they depend.
>
> >     Hindsight is always 20/20, but if we had caved in on that problem
> area
> >     those many years ago, we wouldn't have JSON-LD today. We view
> identity
> >     in the same way, we're not trying to find a solution for identity
> that
> >     works for payments. We're trying to find an identity solution that
> works
> >     really well for the Web, and it just so happens to also work really
> well
> >     for payments.
> >
> > I applaud this work and I really like JSON-LD.
> > You may argue that it brings us closer to a payments standard by an
> > essential providing a piece of the puzzle that you considered to be
> > missing.
> > My contention is that it wasn't really essential to developing a
> > payments standard which is what I believe is the mission of this group.
>
> We'll have to agree to disagree that JSON-LD wasn't required for a
> Web-based, scalable payment standard. :)
>
> > Why not take this work into the appropriate forum and from the
> > perspective of developing a payments standard we can consider it just
> > another arrow in the quiver?
>
> It will eventually move to the appropriate forum. The unfortunate
> reality is that forum doesn't exist right now. If it did, the identity
> work would already live there. This is the same thing that happened with
> JSON-LD. It was incubated in this group until the JSON-LD CG was formed
> and then the RDF WG adopted and standardized the work.
>
> Where do you think the identity work we're doing here should go? Which
> forum should it move to?
>
> > My concern is that by developing an identity exchange standard under the
> > name of a web payments group you have effectively labelled it as a
> > standard for payments.
> > The assumption from anyone outside the group will always be that it is
> > designed for this purpose because the group felt the existing solutions
> > weren't good enough.
>
> That didn't happen for JSON-LD, why do you think it'll happen to the
> identity work?
>
> > I think there needs to be clear messaging that the Identity Credentials
> > work is, as you have said before, an experiment being done "on the
> > sidelines" to test some theories.
>
> Where would you like to see that messaging?
>
> > I need to do a deeper dive but from my first impressions, a lot of what
> > is laid out in the 3 payments focused specs could be done without any of
> > the stand-alone standards.
> > How you exchange credentials, sign messages, represent linked data are
> > all implementation details that can be achieved a number of ways.
>
> Yes, but the point of standards is to nail down the implementation
> details wrt. interoperability. You can't just say "and then you
> digitally sign a message and send it to the payer". Interoperability and
> standards are about /how/ you do that.
>
> > My approach has been to break payments down to the following steps:
> >
> >  1. Initiation
> >     The payee provides the payer with an identifier and optionally a set
> >     of transaction meta-data such as the payment amount and currency.
>
> +1
>
> What sort of identifier is this? Is it a URL? Is there machine-readable
> data at that URL?
>
> >  2. Discovery
> >     The payer uses the identifier to discover the available channels on
> >     which the payee is able to receive payments.
>
> +1
>
> How does the payer extract the information in an interoperable way?
>
> >  3. Channel Selection
> >     The payer selects one or more payment channels from those that are
> >     available and for which payer accepts the terms.
>
> +1
>
> >  4. Invoice (optional)
> >     The payer requests a digital invoice from the payee confirming the
> >     transaction details including the amount, currency,  channel(s) and
> >     terms that will be used to make the payment.
>
> Why is this step optional? If you make it optional, where is the
> consumer protection? What happens if the payer changes their mind? "Oh,
> no, I never said pay me $1 for access... I said pay me $10! - the $1 was
> for the preview that I showed you". Remember, this stuff is going to be
> used for peer-to-peer payments as well. It's not just customer-to-merchant.
>
> >  5. Payment
> >     The payer processes the payment.
>
> +1, if you mean the payer's payment processor processes the payment.
>
> >  6. Receipt
> >     The payer requests a digital receipt from a trusted entity
> >     participating in the payment (dictated by the channel used, usually
> >     the payee's provider).
>
> +1
>
> >  7. Notification
> >     The payer notifies the payee that the payment has been completed by
> >     posting a copy of the receipt to the payee. Alternatively the payee
> >     may receive the receipt directly from their provider.
>
> +1
>
> >  8. Confirmation
> >     The payee confirms that the payment is complete.
>
> +1
>
> > Notice that all of this can be achieved without the payer doing any
> > identity exchange.
>
> Sure, it can happen w/o the payer doing any identity exchange, but that
> only covers a small-ish portion of the number of use cases that we have
> to cover if this payment mechanism is going to achieve what you can do
> online today.
>
> Let's take the example of a movie rental where you have to be over the
> age of 15 to rent the movie.
>
> How do you prove that you're over a certain age? What happens when the
> buyer returns to the website to say, view the rental on the second day?
> How do you prevent the digital receipt from being pirated and used by
> 1,000 different people?
>
> >  1. That the Identity classification is split (or a new category added:
> >     Discovery) so there is a clear distinction between the payer
> >     discovering the channels available to pay the merchant and the
> >     merchant discovering information about the payee.
>
> It's already split out:
>
> https://web-payments.org/specs/#identity
>
> Where else would you like to see the clear distinction?
>
> >  2. That the other steps above be considered for inclusion as categories.
>
> Categories where? I think we've been considering those categories for a
> while and, while it may not be obvious from the website, that's the
> operational model we've been assuming for a number of years now. So,
> this sounds like a documentation problem. Where do you think we should
> document those steps?
>
> >     These specs can be used to solve /other/ problems on the Web.
> >
> > A bonus if it happens but surely a distraction and likely to cause
> > delays? :)
>
> In some cases yes, in others no. You'll have to be more specific about
> what you think is a distraction. :)
>
> Keep in mind that when Web standards go out there, their life span is
> 10+ years. So, we should be very careful to craft a solution that's
> extensible and that is capable of changing with the times. The worst
> case isn't that the technology isn't adopted, it's that it /is/ adopted
> and it isn't flexible enough to keep pace with innovation or it doesn't
> scale appropriately to billions of people.
>
> To put it bluntly: This is the Web, we don't half-ass solutions just
> because we want to make rapid progress. :
>
> Bolting things on after-the-fact is far more difficult than designing
> them correctly from the start.
>
> > Although I'd also propose a standard for each stage and name them as
> > such maybe?
> >
> > Some ideas:
> >
> > Web Payments Initiation (OpenPayee was heading down this road, elements
> > of Web Commerce API)
> > - How to normailse an identifer and optional meta-data into a resource
> > address(es) where the channel discovery, id exchange etc services can be
> > found
> > - Should probably include a means to verify the payee in some way
> >
> > Web Payments Channel Discovery (some stuff from Web Commerce)
> > - Standardised way to represent available payment channels and basic
> > requirements for channels to plug into this system
> >
> > Web Payments Payer Identity Exchange (Identity Credentials?)
> > - Standardised way to request payer credentials etc
> >
> > Web Payments Terms Core (+ extensions for specifying how specific terms
> > would be represented: currency, fees, clearing requirements etc )
> > - Standardised way to represent what terms are understood by both
> > parties, elegant fallback for those that aren't and a means to describe
> > the terms.
> >
> > Web Payments Invoicing
> > - Standardised way to request a digital invoice in which the final terms
> > are described (and calculations done so this only contains final
> > amounts) that is signed by the payee.
> > - Standard format(s) for the invoice, signature etc
> > - Should include a mechanism to reject a request if the terms have been
> > misrepresented or misinterpeted by the payer
> >
> > Web Payments Receipts (stuff from Web Commerce and Web Commerce API)
> > - Standard way to request a signed receipt after the payment is complete.
> > - Standard format(s) for the receipt, signature etc
> > - Standardised means to conclude the payment by sharing the receipt or
> > confirming it's signature or similar
>
> I think these are good suggestions. It feels a bit like premature
> re-arranging, but perhaps we should start a separate thread to discuss
> this proposal. Do you mind starting that thread?
>
> >     > Off the top of my head we should start by defining a standard way
> for
> >     > the payee to advertise the channels that they will accept payments
> on
> >     > (either with a specific transaction context or in a general
> >     > context).
> >
> >     That's what this spec does:
> >
> >     https://web-payments.org/specs/source/web-commerce/
> >
> > Yes and no.
> > I think this spec is the perfect place to start but it highlights what I
> > mentioned before about coming at this from the Web angle first.
> > I know that this the original intention of PaySwarm (as I understand it)
> > was a web based payments system solving problems specifically around
> > digital assets, micropayments and licenses so this is expected.
>
> No, PaySwarm was already intended as a mechanism to make both Internet
> and "physical retail" payments.
>
> > The spec assumes that all of the information about the transaction will
> > be bundled together.
>
> Hmm, why do you say that?
>
> > All the payer wants to know is how much and how do I make the payment.
> > That's all I think the channel discovery standard should solve.
>
> That may be all the payer wants to know, but the regulatory environment
> requires much more to be collected during the sale. Same for the
> retailer and the payment processor. A retail transaction isn't as simple
> as "I want $5, give it to me."
>
> > A completely seperate specification can deal with digital contracts,
> > defining the basket of goods (assets) etc.
>
> Maybe... open to discussion on which spec each of these things go in.
> It's all good as long as the narrative is clear.
>
> > The channel selection or other specifications should allow for this and
> > provide extension points for this explicitly.
>
> +1
>
> > True. But again, I see this as an optional step that doesn't justify
> > thee amount of airtime it's getting.
> > (Maybe my timing in joining the group is just unlucky?)
>
> Your timing in joining the group is exceptionally unlucky... we hadn't
> been discussing identity much until just a few weeks ago. :)
>
> > I see your point but I would counter that by saying, if the major
> > players are adopting that standard the cruft get's quickly hidden from
> > the implementer by being core to whatever library they build on.
>
> Cruft has a fantastically huge cost when you're talking about Internet
> and Web infrastructure. We aren't designing a software library here,
> we're designing part of an infrastructure that 3.4 billion people are
> going to be using by the year 2025. We don't want 70% of that
> infrastructure to consist of cruft.
>
> > Call it simplistic but I see this process as similar to software
> > development.
> > You either find a base library that does most of what you need and
> > extend it or you start from scratch.
> > History tells us that most engineers will always want to go with option
> > 2 but the pragmatic programmer usually goes with option 1 for good
> reason.
> > - No need to become intimately familiar with the internals of the base
> > library
> > - Leverage the hard work and many eyes of the people that contributed to
> > the base library
> > - Benefit from the constant improvements and updates to the base library
>
> IMHO, looking at Web and Internet architecture design in those
> simplistic terms is a recipe for disaster. :)
>
> Designing technology and protocols for the Web is a different beast than
> standard software development and engineering.
>
> I understand the analogy that you're making, but having participated in
> the standards-making process for a while now, software engineering and
> Web standards engineering only share a few things in common.
>
> You build on top of standards that are useful, that much is true.
> However, building on top of standards that contain 70% cruft is a good
> indicator that what you're building on top of is probably not a good fit
> for what you're doing.
>
> Again, I'm not saying that OpenID Connect is 70% cruft, or that OAuth2
> is not useful. I'm saying that from what we've experienced to date, they
> didn't drop in as easily as some of the other technologies we've decided
> to build on top of (like RDF, JSON, JSON-LD, AES, HTTP Signatures, HTTP,
> URLs, etc).
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: The Marathonic Dawn of Web Payments
> http://manu.sporny.org/2014/dawn-of-web-payments/
>
>