Microsoft open-sources clever U-Prove identity framework

U-Prove, a powerful framework that couples strong privacy with high security …

More and more personal, private information is being used and stored online than ever before, and at the same time, attacks on that information are increasing in frequency and sophistication. Phishing is a growth industry—it's very profitable to trick people into handing over names, passwords, credit card numbers, and so on, so that their finances can be pillaged. Important activities like banking and filing tax returns are being performed, and these need strong proof of identity. On the other hand, there's no reason why a storefront like, say, iTunes, needs to know your identity; it only needs to know that the money being handed over is yours to hand over.

Ultimately, we want to be able to securely make transactions without giving third parties the ability to masquerade as us; we want to be able to visit websites and make purchases without those sites being able to track us or combine different pieces of information to draw a more complete picture of us; we want to be able to be able to disclose some information about ourselves, but not everything. The U-Prove framework, released as a CTP today by Microsoft, aims to solve these problems.

With current systems, there's no good way to prove your identity to those sites that need verification, and conversely, there's also no good way to restrict what you inadvertently reveal to those sites that don't need your identity. To use a credit card on iTunes, I have to hand over so much information that Apple, if it was a bad actor, could masquerade as me. I can't just give Apple some electronic money; instead, I have to give them my name, address, and credit card number. In practice, the real problem with me handing over so much info to iTunes isn't that Apple might pretend to be me—with billions in the bank the company doesn't really need to charge things to my credit card, after all—but that hackers (both external and internal) might take this stored data and use it for their own nefarious purposes.

And these are not hypothetical concerns. An estimated 222 million records were exposed in 2009 in a wide range of data breaches. Many occurred in banking and government systems (systems which arguably do need to retain a significant amount of personal data), but more than half were disclosures by businesses, many of whom only retain private information because current technology gives them no choice. If convenience features like automatic "click once"-style payments are to be offered by these companies, they have to retain information about my name, address, credit cards, and so on.

The U-Prove system is designed to be a solution to this problem. It was put together by respected cryptography researcher Dr Stefan Brands. He created a company to develop and market U-Prove, Credentica, which was bought by Microsoft in March 2008. With U-Prove, identity information can be used securely, and private data can be safely shared to those parties that need it, without leaking more information than is required.

U-Prove allows the creation of secure ID tokens, which are pieces of data that incorporate whatever information I need for a given task—but no more—along with cryptographic protection to ensure that they can't be forged, reused, traced back to me, or linked to other tokens that I have issued.

In a world with U-Prove, many existing identity management problems would go away. If my credit card company and online music service both supported U-Prove, I could create a token that allowed a single limited electronic money transfer from my card to the music company, without disclosing my name, address, or date of birth, and without that token being usable to make further purchases. Similarly, I might want to buy a computer game from an online store, the same situation as before, but this time with a twist: the computer game is rated 18+. So to make the purchase, I have to reveal my age, as well as the money transfer, to the online store. U-Prove lets me do this, but still doesn't require me to reveal my name, address, or any other irrelevant detail.

An hour-long presentation by Dr Brands describes how U-Prove works and how it achieves what it does (with even more detail available in his freely downloadable book). It builds on existing public key cryptography concepts, but adds to them the important ability to hide data. Normal public key cryptography is something of an all-or-nothing affair—to prove that a particular piece of data was encrypted by a particular person, you need to know the data. U-Prove allows that proof to take place without revealing all the data.

All of this is useful, but it suffers a substantial chicken-and-egg problem. Users don't have U-Prove, and have no incentive to get it, because service providers don't support it anyway. Without identity providers (governments, banks, credit card companies), users, and service providers all agreeing to use the system, it's unfortunately pointless. Systems similar to U-Prove have been tried before, but typically they've demanded money from both users and service providers alike to integrate the software. Outside narrow niches, this is an unappealing prospect—they're paying to integrate a system that no one uses anyway.

On top of this, Microsoft has dabbled, unsuccessfully, in this area before. In 2001, the company announced its Hailstorm platform. Hailstorm was a set of Web services, integrating with the company's Passport authentication system (now known as Windows Live ID) that allowed users to authenticate with third-party online applications and provide them with varying access to personal data stored within Passport. Hailstorm was, however, a centralized system, with key portions owned and operated by Microsoft. The software community balked at giving Redmond this much control—massive centralization is not an acceptable approach to the identity problem—and Hailstorm, along with third-party usage of Passport, was killed off.

It is for these reasons that Microsoft has released its U-Prove SDK using the open source BSD license. Source code is available in both C# and Java, and the technology is covered by Microsoft's Open Specification Promise. This is a irrevocable promise by Microsoft that the company will not assert any claims against anyone using the technology that relate to any patents covering the technology. By releasing the technology under a permissive license, and by making a legally binding agreement that patents covering the technology will not be used in legal action, the company hopes that there will be no barriers to using the system for both service and identity providers.

In addition to this core technology, Microsoft is integrating U-Prove into a range of its own identity products: Windows CardSpace 2, Active Directory Federation Services 2, and Windows Identity Foundation. These technologies, codenamed "Geneva," provide identity management facilities to end-users, administrators, and developers (respectively), allowing each of those groups to integrate U-Prove into their existing systems. As well as pure software systems, U-Prove can also be integrated with smartcard systems to provide multi-factor authentication and various other features.

Unfortunately, the reality is that U-Prove adoption still faces an uphill struggle. The desirability for end-users is clear; it permits both secure and private use of online services, and should offer substantial protection against many of the online threats currently faced. It will substantially mitigate the damage caused by the kind of commonplace security breaches, and allow a much higher degree of privacy than is currently possible. Identity providers—governments, banks, credit card companies—might also like the system. Credit card fraud costs credit companies and banks money, after all—a secure system for online payments would undoubtedly be preferred.

Online service providers, however, are a slightly different story. U-Prove allows meaningful privacy. Obviously, if I'm buying something from Amazon and need it to delivered, I need to give Amazon a delivery address. This kind of information disclosure is unavoidable. But if I'm just downloading an MP3 from the company, they don't need to know where I live (perhaps they need to know my country, but certainly not my full address). If Amazon supported U-Prove, I could make both these transactions, and Amazon would not even be able to know that it was me both times—that's the level of privacy it provides. Except that Amazon probably wants to know. Amazon, as with many other online service providers (king of these being Google), makes extensive use of shared data to make suggestions, both to me and other shoppers. If I take away Amazon's ability to link purchase data, to determine trends and patterns, Amazon becomes that much worse off.

This ability to mine data is increasingly important. It's why so many brick-and-mortar stores offer loyalty cards these days—loyalty cards let them track my habits even when I use (otherwise untraceable) cash. A reliable, effective system that allows private purchasing would diminish that data mining capability, to the detriment of the vendors.

This is a pity. The technology is clever, and the capabilities it offers would make the online world a great deal safer. But outside of certain closed systems—large corporations wanting to govern access to their own internal systems, for example—it's hard to see U-Prove ever taking off.

41 Reader Comments

Sure... As the article rightfully point out at the end, the big big stumbling block of all this, is that all this personal data is something of great value for online businesses.

There could be reasons why such a scheme could take off: if ID fraud became such a problem that online businesses became be willing to forgo part of their data mining capabilities in exchange for bringing back customer confidence, or if the legislator stepped in and made such schemes compulsory for the sake of customer protection...

NOTE: if you're already signed in to connect, you may get a "Page not found" error back ("The content that you requested cannot be found or you do not have permission to view it"). Just sign out from connect and then it should load fine.

"On top of this, Microsoft has dabbled, unsuccessfully, in this area before. In 2001, the company announced its Hailstorm platform"

The reality is that this effort was part of the work surrounding the Windows 2000 development of Active Directory. That work was a big success for Microsoft in managing Windows domains and also a substantial step towards building on standard technology including DNS, LDAP, and Kerberos. The other reality is that the IETF has floundered for decades in trying to seed a public infrastructure to support internet security. Windows Security Foundation appears to be Microsoft's next big effort to move forward in this area. It is intended to move beyond Active Directory by providing a completely open identity system. Authorization is achieved with claims that are specified in a few simple text formats. Implementation and deployment of this approach is probably the biggest hurdle in getting to a world of interoperable web services. It is impressive the Microsoft already has the approach supported in the 2010 version of Sharepoint. I suspect we will see a major ongoing effort for Microsoft to try to work with Yahoo, Google, Amazon, and other major service providers to try to get a pervasive open identity system established. But it still remains to be seen when if ever we will have an internet identity and security system that has the kind of success that DNS has enjoyed.

Well, to take Amazon as an example, they could still require site registration to make a purchase, thus tying all the purchases you make, whether they're digital or physical. I mean technically you don't have to use the same CC every time you purchase from amazon anyway.

In fact, unless Amazon allows purchase w/o registering they're probably not creating your "profile" based on your CC but based on your actual profile on the site.

Basically, what I'm saying, is that there are ways to encourage people to allow companies to form "profiles" of us for purposes of advertising, while still using a system like U-Prove to offer enhanced protection.

Take Steam for example, technically they don't need my address of course since all products are digital, but even if I were allowed to provide them w/ CC number only without name and address, they'd still know my game purchasing habits because they require registration.

U-Prove allows the creation of secure ID tokens, which are pieces of data that incorporate whatever information I need for a given task—but no more—along with cryptographic protection to ensure that they can't be forged, reused, traced back to me, or linked to other tokens that I have issued.

And *that* is the sum total of actual content in this article. I kept waiting to get to the meat. Five grafs of "phishing is a problem, Microsoft has something to address the problem", one sentence with a 100,000-foot-view summary of the solution, then ten grafs explaining that new technologies face barriers to adoption and some history about Microsoft's previous efforts in the space.

I don't need every ARS article to be jargon-filled and deeply technical. But this article is somewhat less technically detailed than I would expect out of Time magazine. Hopefully this isn't a conscious direction change from ARS.

For the longest time, I've wanted something much simpler: the ability to create restricted credit card sub-numbers for particular transactions. For example, I'd like to be able to create a sub-account for Comcast that only allows $60 a month to be paid out *to Comcast*, or a different sub-account with no personal information attached to be paid out for a fixed amount to <some perhaps dodgy online retailer> (I can buy gift cards for this latter use case, but it's a bit annoying.)

(This would have the added bonus of not blowing my automatic bill pays all to hell if I lose my credit card.)

Hurdles? How about C sharp and Java only, for simple starters, to say nothing of the other issues stated in the article, or in the comments here. Unless/until they get turnkey implementation packages out there, freely downloadable, for PHP, PERL, python, and so on, well, it ain't happenin'. Ever. Look at PHP itself, for an easy example. If there weren't packages freely available for at least the most widely used server operating systems, then we would never have heard of it; it would have died in the hands of hobbyists. "Open" means almost nothing if every shop has to fully develop their own implementation of the damned thing.

It's why so many brick-and-mortar stores offer loyalty cards these days—loyalty cards let them track my habits even when I use (otherwise untraceable) cash.

This isn't true, at least in the US. You might only need to use a loyalty card when you want to get sale prices and sometimes not even then.

That's the carrot to get you to use the loyalty card. The point of the loyalty card, from the vendor's perspective, is enhanced data mining ability. Some loyalty programs have incentives for associating all purchases with the loyalty card.

For the longest time, I've wanted something much simpler: the ability to create restricted credit card sub-numbers for particular transactions. For example, I'd like to be able to create a sub-account for Comcast that only allows $60 a month to be paid out *to Comcast*, or a different sub-account with no personal information attached to be paid out for a fixed amount to <some perhaps dodgy online retailer> (I can buy gift cards for this latter use case, but it's a bit annoying.)

(This would have the added bonus of not blowing my automatic bill pays all to hell if I lose my credit card.)

I know there is - or was? - at least one CC company that supported on-demand generation of random, single-shot CC numbers for online purchases. Which isn't quite what you're asking for, of course, but would accomplish some of the same goals.

I keep hoping that such a service becomes commonplace amongst CC providers, because I would love to use it...but not enough to switch banks/card providers to get it. (I realize this is the reason it isn't becoming commonplace, in microcosm).

For the longest time, I've wanted something much simpler: the ability to create restricted credit card sub-numbers for particular transactions. For example, I'd like to be able to create a sub-account for Comcast that only allows $60 a month to be paid out *to Comcast*, or a different sub-account with no personal information attached to be paid out for a fixed amount to <some perhaps dodgy online retailer> (I can buy gift cards for this latter use case, but it's a bit annoying.)

(This would have the added bonus of not blowing my automatic bill pays all to hell if I lose my credit card.)

I used a similar service from Chase or someone a couple years ago. You can generate a one-time virtual CC number online and even specify a maximum transaction amount it's good for and whether it can be used for recurring charges. The balances all come back to your real account, but I don't think it helped to hide personal info because almost all online retailers still required you to provide those.

Unfortunately, I'm sure this will die out like every other identity solution that has come along, in favor of "simplicity" (the old way of doing things), which is, ironically, less simple. And all because the people making the policy decisions at major retailers (the sites that actually matter for a technology like this to succeed) will either not understand the technology, don't like change, or believe that it will add complexity to their processes. That is, of course, unqualified speculation based on cynicism, but time will tell.

And that's too bad, because I'd really like to see something like this succeed.Perhaps if Microsoft throws enough "incentive" money at it, they can entice a few big names to adopt it.

So what kind of client would one embed this technology into - is it something that a Browser should do? Firefox plugin? Implement it in Flash? I guess since there's a Java version it could be built into an Applet, although that's not ideal.

Despite the fact that it comes from Microsoft, it sounds like this would be a good idea, but it needs to be available on a significant proportion of users' PCs before any service providers are going to be interested in accepting it.

Second: This is some awesome tech. Wonder if it would be feasible to try and get the governments to push it. I know that german government is already saying that there is too much private data flowing around and this could solve quite a few problems. (I guess it's time to send some e-mails around).

From an Information Technology / Information Security perspective this would be an invaluable resource to have integrated as part of AD/directory system. No longer having to enter in user information to setup users and contact information. User creation could be as simple as adding the U-Prove (or I guess any other universal identity management service) identification to the system and voila! The user is created and since no personal info is stored at the company the risk of managing that info should disappear. HR department breaches, or losing USB keys or laptops loaded with personal info could be a thing of the past. On the other side of the this equation it should go without saying that that the User should have FULL control over what information is allowed to be viewed by different entities, for any given reasons. Take for example HR/Finance trying to process payroll. They hand off the identification number to the payroll processing to handle all the taxes and financial details. This could continue down and out in many different directions for information management. All the time the USER gets to control which companies (and even departments or groups) had access to which information.

OAuth is for credentials to log in not quite sensitive information like credit cards.

Unless I'm mistaken, you're getting OAuth confused with OpenID. From the OAuth website : This is what OAuth does, it allows the you the User to grant access to your private resources on one site (which is called the Service Provider), to another site (called Consumer, not to be confused with you, the User). While OpenID is all about using a single identity to sign into many sites, OAuth is about giving access to your stuff without sharing your identity at all (or its secret parts).

Stores can still choose to insist on you registering and being identifiable (for DRM purposes for example) but you both still benefit of the one-time nature of the actual payment.

Alternatively stores that don't need you to be identifiable could offer one price for an anonymous purchase and a discounted price if you logged in with you registered profile. The store would gain some customers who would not normally register to buy from them, and the customer benefits by having the choice of anonymity when they want it (for Valentines gifts from a joint account for example).

This would be nice. One of the things I really dislike about pay pal is that any time you make a purchase your name is sent to the other person. That might not be a problem for John Smith, but my last name happens to be extremely unique. It wouldn't be too hard to track me down.

Please correct any misunderstanding here, but it seems to me that the user still has to trust a "U Prove" provider to obey the user's instructions. Is this not correct?

The Microsoft page linked from the article offers a "white paper" and spec document, but I've been unable to download them even after turning on javascript and cookies. It seems to require some sort of proprietary download manager.

Quote: "To use a credit card on iTunes, I have to hand over so much information that Apple, if it was a bad actor, could masquerade as me". This is a strawman argument, that points merely to the futility of today's systems but doesn't make a strong case for U-Prove. To my mind, the technical problem to be solved is simple. We do a good job of identifying people in the real world and conferring credentials on them (credit cards, driver licences, association memberships, university qualifications ...) but we do an awful job conveying those credentials on line. We use identifiers as handy proxies for credentials (aka identities, each meaningful on a defined domain) but we don't protect those identifiers against replay or counterfeiting. Identifiers on their own are privacy enhancing but when they cannot be trusted, and need to augmented with auxiliary personal information (like billing address and CVV) then they lose their benefits. There is no great technical difficulty protecting identifiers by public key cryptography, such that the receiver can be sure that (a) the identifier is genuine, and (b) it was presented with its owner's consent. Moreover, this presentation of signed identifiers can be done with user-controlled chip-enabled devices and can be checked by servers using local PKC libraries. My problem with the Identity Metasystem and U-Prove is that they introduce complex architectures and business models in order to solve what is really a simple problem. Cardspace introduces token servers and identity issuers etc. These are brand new concepts, for the most part foisted upon businesses that just want to do online what they've been doing in teh real world. I do not believe that banks ordinarily see themselves as "identity issuers", not in any abstract sense in which the identities they issue in their own closed domains suddenly become commodities in an open trading scheme. Banks need to be convinced to see themselves in this novel way; I've participated in these conversations many times between bankers and federated identity advocates, and seen that bankers are resistant, and rightly so. This opening up of silos seems intuitive to many but whenever it's been tried in practice (and I’ve worked on three such major projects), it proves to be impossible to manage the risks. What bank can be comfortable issuing an identity to its customers that is good for unanticipated transactions with merchants having no relationship with the bank? How can anyone even start to do a risk assessment on that? Experience shows me it's much better to make do with the various identities we already have than to try and re-use identities across domains they were never intended to support. Regarding U-Prove, it's rather over-engineered, with its aim of proving unanticipated assertions between strangers. This is really a rare scenario. What's much more common is the need to prove *anticipated* assertions (like credit card numbers) between parties who actually know each other, or at least who are transacting in a well defined context (shopper to store, customer to bank, patient to doctor, user to OSN, doctor to pharmacist etc etc). So I reckon the barriers to success are even more fundamental than discussed in the article. The challenge is that these solutions are over-engineered and deeply novel, whereas the digital identity problem is really very simple.Stephen WilsonLockstep Technologies.

Great article. I'm a security professional with a good understanding of federated identity, and I read six articles about U-Prove before and got bored before getting a decent idea of what was in it. This article is well balanced away from not being understandable for the lay men and being void of actual content. Jus a little bit more technical details at the end about how U-Prove works would have made it even better.

Is it really a new idea? Not at all. Any different from Microsoft Passport? Negligible since seller cannot relate your Passport ID to real person anyway. Two of the decade-old problems remained the same: (1) what happen if the transaction gone wrong? Say, the seller does not deliver what it claimed; (2) I have to trust all my privacy on U-Prove.

Many occurred in banking and government systems (systems which arguably do need to retain a significant amount of personal data),

They do? For what? I question that premise completely. they only need the minimal amount of information about me in order to do business the same way anyone else does.

Quote:

Stephen Wilson . We do a good job of identifying people in the real world and conferring credentials on them (credit cards, driver licences, association memberships, university qualifications ...) but we do an awful job conveying those credentials on line.

We do? Based on what? piece of paper SSN. piece of paper birth certificate. drivers license based on pieces of paper.

Under any DRM scheme or one whose feature is a link to a library or memory, the purchase ties to an account, rather than being self-standing and independent. This does seem to offer the digital version of cash purchase anonymity.

Given many vendor's desire to automatically re-up services by charging credit cards, I'm not sure I see a drive for vendor adoption.

Hurdles? How about C sharp and Java only, for simple starters, to say nothing of the other issues stated in the article, or in the comments here. Unless/until they get turnkey implementation packages out there, freely downloadable, for PHP, PERL, python, and so on, well, it ain't happenin'. Ever. Look at PHP itself, for an easy example

Dude, get over yourself. Those aren't languages used widely to develop enterprise ecommerce sites. Your LAMP languages are a fairly insignificant minority in that space and not at all an impedement. Where LAMP support would be useful is the 8 million tiny online retailers that had some cut-rate web contractor throw together a site for them, one written very likely without any knowledge of the current security landscape or coding best practices, has never had static analysis run on the code (only a handful of static analysis tools even support PHP and that is a recent development, because it isn't something enterprises care about. None of the major vendors support perl or python), and has certainly never had a penetration test performed on them. At best they have the worthless McAffee scan done periodically, which is as effective as Jeremiah Grossman's PCI-SCANLESS logo program. Or in other words, the utility of having U-Prove for LAMP languages is that it removes PII from the websites that are the easiest to compromise. (also - perl? 1999 called, they want their CGI back). It doesn't get you adoption in the major retailer space though, and that is the adoption that is important.

Quote:

I have to trust all my privacy on U-Prove.

So you have to trust your privacy with one broker instead of every retailer? From a confidentiality standpoint a single broker is the better course, as it is a single broker whose entire engineering effort is to design a secure identity and payment system rather than a a million retailers whose primary effort is to design an online retailer, with identity management being largely a side thought. Now from an availability standpoint a single broker creates a single point of failure which is a different concern. (and considering I was in Europe when the Visa payment network went down, I can appreciate the ramifications of a failed payment system) but has little to do with privacy.

Many occurred in banking and government systems (systems which arguably do need to retain a significant amount of personal data),

They do? For what? I question that premise completely. they only need the minimal amount of information about me in order to do business the same way anyone else does.

Yes, they do. To send your bank statements to the right place, to conform with money laundering regulations, to perform credit checks, they need to know these things. Banks are pretty regulated, they can't just give accounts to "earl grey".

Call me a cynic but I am sure that there will be no big government push toward securing the internet better in this manner. This would give people more control of what kind of information they give up online.

Also, the premise that we manage off-line identification well is a farcical proposition. Identity fraud is a fast growing crime and it is far too easy to perpetrate. I myself have had someone else purchase a contract phone in my name and I bet nearly everyone knows a victim of a similar crime.

Stephen Wilson also blithedly ignores the fact that U-Prove is not merely to facilitate the "unanticipated assertions between strangers" but mainly to limit the information that needs to be disclosed for exchanging "*anticipated* assertions (like credit card numbers) between parties who actually know each other".

A major example for me would be the number of sites who demand a date of birth to verify age. All the want to know is whether I am over or under a certain age, I should not need to disclose additional data which is valuable to fraudsters.

Another one could be the authorisation to borrow library books, for various reasons in the US the guarantee that your reading habits aren't being monitored has been quite a major concern. For that matter what about access to medical services which might have social consequences and hence people prefer to access anonymously?

In all these cases accidental (or deliberate) information disclosure are much less likely when using Zero Knowledge Proof authentication systems.

Regarding U-Prove, it's rather over-engineered, with its aim of proving unanticipated assertions between strangers. This is really a rare scenario. What's much more common is the need to prove *anticipated* assertions (like credit card numbers) between parties who actually know each other, or at least who are transacting in a well defined context (shopper to store, customer to bank, patient to doctor, user to OSN, doctor to pharmacist etc etc).

I don't think so.

Shopper to store does not require the store to know my name or date of birth. It requires a delivery address, for physical items, but that does not need to be my home address. And yet presently, I have to disclose many of these things: my home address, my full name, my credit card number. Even for electronic delivery! With U-Prove I would not need to disclose any of these things.

And for the most part, the purchases I make are with strangers. Sometimes they're repeat business, oftentimes they're not, but they're almost all strangers.

And both strangers and non-strangers are at risk of data breaches. All the more reason not to tell people details unnecessarily.

[The] premise that we manage off-line identification well is a farcical proposition. Identity fraud is a fast growing crime and it is far too easy to perpetrate. I myself have had someone else purchase a contract phone in my name and I bet nearly everyone knows a victim of a similar crime.

Stephen Wilson also blithedly ignores the fact that U-Prove is not merely to facilitate the "unanticipated assertions between strangers" but mainly to limit the information that needs to be disclosed for exchanging "*anticipated* assertions (like credit card numbers) between parties who actually know each other".

I haven't blithely ignored either of thiese points.

The vast majority of identity theft is digital identity theft. When I say off-line identification is managed well, I mean that it's rate for people to obtain fraudulent SSNs, credit cards etc. from scratch. Instead what fraudsters to do is co-opt existing IDs, and then either abuse them directly, or parlay them into more elaborate IDs.

On the second point, I am all for minimising information that needs to be disclosed. The point is that for anticipated assertions like credit card numbers, you can use conventional mature PKC and you don't need anything as novel as U-Prove.

... much more common is the need to prove anticipated assertions (like credit card numbers) between parties who actually know each other, or at least who are transacting in a well defined context (shopper to store, customer to bank, patient to doctor, user to OSN, doctor to pharmacist etc etc).

I don't think so.

Shopper to store does not require the store to know my name or date of birth [or] my home address, my full name, my credit card number. ... With U-Prove I would not need to disclose any of these things. And for the most part, the purchases I make are with strangers. Sometimes they're repeat business, oftentimes they're not, but they're almost all strangers.

I totally agree about the need to not disclose extraneous information. But when the context is clear (like shopper to merchant) then U-Prove is overkill, and it's totally novel to boot. To assert your credit card number and nothing else, you just need to digitally sign it using conventional mature PKC.

When you shop online with a credit card I maintain that you are not in fact a total stranger to the merchant, even if you have never visited them before. You have a supposedly trustworthy credit card issued within a scheme that the merchant is a party to. They might not know you personally (indeed, we're all agreed that they ought not to know you personally but they do know your credit worthiness via your card. Or at least they would if the card number on its own were dependable.

... yet presently, I have to disclose many of these things: my home address, my full name, my credit card number.

Dr Pizza, are you saying that it's undesireable for the merchant to know your credit card number? My view is that if we could stop credit card numbers being ripped off and replayed*, then it's perfectly safe for merchants to know them. Indeed, it's very very desirable for merchants to deal with credit card numbers because there is 40 years worth of mature legal arrangements around the Four Party card processing model. One of the huge but unsung costs of all the new models where credit card numbers are suppressed -- like the old SET, or its complex present day progeny 3D Secure, or all the zero knowledge approaches like U-Prove -- are that they change the legal arrangements between cardholder. merchant, acquirer and issuer, and introduce brand new parties. It is highly desireable that new security technologies leave the conventional Four Party model unchanged. Public Key Crypto can do this by signing transactions between shopper and merchant (ideally using hardware like a Chip-and-PIN smartcard, or a smartphone), and then pushing the verified transaction into the acquiring bank as with any bricks-and-mortar payment.

* PCI-DSS has some effect on stopping credit card numbers being ripped off but it does absoluetly nothing to stop card numbers being replayed once stolen.