Verify a user's affiliation with an organization

Question

I'm in charge of IT at a students' organization. Let's call it FratA. FratA has ties to sister-organizations in other university cities in my country. Let's call those FratB through FratZ. These inter-organizational ties are formalized by an umbrella organization, of which FratA-FratZ are members. Let's call it SuperFrat.

SuperFrat is planning an event for all the student members of FratA-FratZ, and wants to sell tickets to the event using a web store provided by TicketSellingCorp. However, the sale of tickets should be limited to members of the organizations FratA-FratZ.

TicketSellingCorp has approached me with an unusual inquiry:

We want users to type in their username and password to the FratA-website,
 so our web store can log in behind the scenes, scrape their personal/contact information
 from their normally protected profile page and use this information for ticket sales.
Don't worry about security, we won't store passwords, and our backups are encrypted.

The main problem is that once logged in, our members can not only access their own information, but also a lot of information about other people. So if member Alice does not agree with TicketSellingCorp's proposed implementation, her information would still be exposed to TicketSellingCorp if Bob does agree.

I told TicketSellingCorp that I think this is a bad idea that conflicts our members' interests, and I offered them an openID provider (including an OSS sample client implementation) for the FratA-website; one that only tells the openID client that authentication was successful or not. It does not even share any information, such as an email address. My motivation for that is that TicketSellingCorp can ask users for that themselves, so users are responsible for sharing their own information.

TicketSellingCorp's response to this was:

We cannot implement openID in our sales process.

Is there another way to cooperate with TicketSellingCorp that does not involve exposing all our members' personal information?

Answer 1

How about generating a special code for each user that can be entered on TicketSellingCorp's website? You can give TicketSellingCorp a list of valid codes. TicketSellingCorp can ask users for their name and other personal info when registering, and this could optionally be checked against your own database later.

The codes should be generated randomly to prevent people from guessing other people's code (impersonating them). 128 bits of randomness should be more than enough to make sure they can't be guessed. For example an easy way to get codes is to get 16 bytes of output from a secure pseudo-random number generator (/dev/urandom or in PHP openssl_random_pseudo_bytes), then convert it to hexadecimal and store it somewhere in the database.

If TicketSellingCorp is really set on logging in with the user's account, you could make the codes work as secondary passwords that only give out certain information. Also if they're so set on doing that, I'd trust them even less.

Answer 2

We found another way of doing things: When users are signed into our website, they'll find a link that takes them to the company's "become a customer form". Part of this link are two request parameters: one (pseudo)randomly generated number, and an encrypted version of that number (a digital signature). The encryption happens asymmetrically (with our private key), and we gave the company our public key. If they can decrypt the second value, they know that the user came from us.

It's not very elegant, imho, but it works well enough.

The reason we did not opt for Luc's answer is that we suspected that our users would not understand the procedure. Also, after some back and forth with TicketSellingCorp, it turned out that they were more flexible than they initially presented themselves.