Apple Successfully Implements OpenID Connect with Sign in with Apple

Many delivery providers need to be able to contact the person they are delivering to. This is standard practice. The same is true for many non-trivial payment providers (such as PayPal/Klarna).

This data is shared for the legitimate interests of the customer. You've bought something and asked to a) pay for it, and b) have it delivered. I think it's reasonable to expect that the companies involved in this can contact you for the purposes of fulfilling your request.

This is all done under GDPR. The companies hold the data only for as long as they need, for the purposes explicitly requested by the user. This will all be included in privacy policies.

> It also seems that you could set up your own relay allowing those providers to contact your customers.

This might be technically possible, but introduces many concerns such as deliverability and spam ratings. Relaying email in this way is non-trivial when you're doing it at scale. For services sending ~100k emails a month or more, this requires careful planning because it's very easy to become filtered as spam.

I don’t.

> I've rarely seen vendors sharing e-mails with payment and shipping companies

If it was done correctly, odds are good you wouldn't even know those emails originated from a third party vendor. Plenty off stuff you order is fulfilled by third party vendors who specialize in payment & logistics.

For example, if you ever ordered contact lenses from costco, the whole damn thing is driven from vendor called "WVA"[0]. I'm pretty sure it is completely turn-key. Only way I figured out what was going on was looking at the return address in streetview.

I ordered a lockpicking from an online vendor and it was fulfilled by some logistics provider on the east coast. Same kind of thing...

So I'm not actually sure what your problem is, but plenty of businesses have a need to share your contact information with their vendors.

[0] https://wisvis.com/

Shameless plug (but I hope that's okay, again): IRMA Authentication is an open-source app [1] and protocol that offers privacy-friendly attribute based authentication and signing using Camenisch and Lysyanskaya's Idemix [2].

It's currently heavily focused towards The Netherlands, where citizens can obtain attributes such as name, home address and age. These attributes can then be selectively disclosed directly to a service provider, without the identity provider being able to see the transaction [3]. Multiple disclosures are also unlinkable as long as the attributes themselves are not identifying.

The fact that the identity provider is not at all involved with the transaction is an enormous privacy win compared to OpenID Connect, especially in the case of centralizing providers such as Apple – and less so in for example the domain of education single sign-on.

It's not currently using the verifiable claims data model, but it would very much fit it. It also doesn't use a 'blockchain', simply because it's not necessary to do so, and makes it all a lot less complicated.

[1] https://github.com/privacybydesign

[2] https://privacybydesign.foundation/publications/

[3] https://privacybydesign.foundation/meeting-slides/slides-8-3...

Usually you offer a connect button with the most popular providers. You could also detect a login with somename@whateverapplemaildomain in order to passthrough for those addresses. There are some discovery mechanisms that can be added for DNS/http(s) services as well against different tlds.

In the end, probably would just add an apple-logo button next to twitter, google and facebook auth buttons.

----

Aside, in terms of data storage, separate the account, user and login/auth details. An account is related to activity inside the system. A user is a person authorized to use/act on or as that account. A login is an authority and related information to enter as a given user. Logins can be an OpenID reference, AD Integrated User, an API token, a local password entry (salted/hashed of course).

If you make the separations above, you'll have far fewer issues if/when you need to make your application more flexible in terms of users/authentication against accounts. It also is very helpful when you will have "individual" accounts and "business entity" accounts, which may have variances in UI/UX.

Beyond this, would separate the actual API/UI systems from auth systems relying on integrated tokens (like RSA signed JWT on an internal authority). In this way, your API systems only need to worry about "allowed" signers, and the roles assigned in the token's claims. Of course then there are issues with token lifetime, refresh and revocation to consider.

Sorry for the blathering on this, literally working on an authentication management system (fairly barebones initially) right now. MVP at end of day after 4 months work.