- From: Mike Varley <mike.varley@securekey.com>
- Date: Tue, 22 Mar 2022 18:57:44 +0000
- To: Joe Andrieu <joe@legreq.com>, Credentials Community Group <public-credentials@w3.org>
- Message-ID: <YT1PR01MB3099AA1C55DA159AC1C09F5DE4179@YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM>
Hi Joe, I think you made a very interesting comment and I wanted to call it out as I think it may be very helpful in focusing this discussion:
> If you're saying the issuer wants to also be a verifier, that's fine. But lets not conflate the two. Acting as an issuer has a different set of responsibilities than acting as a verifier.
So, what are the responsibilities for an Issuer?
And for a Verifier?
Should we come up with a set of (high level) criteria/responsibilities/guidance for these roles? Maybe if we can clarify this a bit, then we can look at the wallets/protocol responsibilities to match…
Something like:
* Issuers that expect their credentials to be useful only for the subject they are issued to need to pay close attention to holder software capabilities for subject authentication, private key protection, and portability between holder software (versions and vendors).
* Issuers that expect their credentials to be userful in conjunction with other forms of subject binding (for example a bearer token wrt. Birth certificate needs to be presented with other forms of ID) are less restricted on their holder software choices.
* Issuers that expect their credentials to be used in a pseudonymous manner (where the holder software does not become a source of cross-domain tracking) must consider holder software that supports that feature
* Issuers should expect their subject base to have a range of wallet software available to them, and therefore should support protocols that enable the Issuer to ‘discover’ the wallet (and vise-versa) as opposed to direct holder software integrations. Open discovery protocols also allow Issuers to scale with the ecosystem as it grows.
* …
Would folks find these kinds of criteria useful in the discussion – or is it a distraction? (ie, we’ve already figured this out so it is a wasted exercise, or any protocol we come up with should meet all criteria everywhere ever so nvm…) ?
(note I am deliberately focusing on “personal” credentials as the topic is related to OIDC).
Thanks,
MV
From: Joe Andrieu <joe@legreq.com>
Date: Tuesday, March 22, 2022 at 1:56 AM
To: Credentials Community Group <public-credentials@w3.org>
Subject: Re: Centralization dangers of applying OpenID Connect to wallets protocols (was: Re: 2022-2026 Verifiable Data Standards Roadmap [DRAFT])
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. To report a phish, click on the “Report Phish” button.
On Mon, Mar 21, 2022, at 5:02 PM, Tobias Looker wrote:
Manu, see below for some responses to your latest email.
> Advocating for an exchange protocol where the wallet provider is never
mandated to register itself with an issuer for credential issuance exchange.
I continue to be confused with your framing of registration as the problem here, I think you mean a protocol where the
wallet provider identifies itself, in the flow, is the actual issue? Registration is just a way to do the bulk of this
once? I also dont see how this is materially different to the wallet feature VC approach either w.r.t centralizing forces that result.
I'm also confused, but mostly because I think I'm with Manu here, but the way Tobias is engaging makes me wonder if we're talking about the same thing. Folks seem to be talking past each other.
There are two angles I'm seeing here where registration does and doesn't make sense.
Where it doesn't make sense is attempting to verify a particular software implementation of a client. There's a reason the web doesn't do this. There are even better reasons why cryptocurrencies don't.
The fact is, you can't trust the client to be honest about itself. Ever. You have to assume that whatever magic sauce you might bake into the client will be reverse-engineered and reused by apps by distilling the "secret" and applying it themselves. Once you put the secret in your binary, you may as well just publish it because you do publish the binary.
In all cases, you should assume the client is hostile and act accordingly. Cryptocurrencies push the authenticity question to the key store. You don't have to trust the client software that communicates your signed transaction, you just have to trust the hardware device that actually does the signing (however your setup works).
To the extent that the advocacy is to enable some sort of allow-list for wallet implementations, that's a huge security hole and should be avoided. It will only ever give you a false sense of security. Instead, check the math on the proof, is the proof valid? Then who cares what software delivered it? You certainly aren't going to allow-list all of the hops on the network, so why would an allow-list for the client software make any sense? I believe this is the point Manu is attempting to make and I agree with this point.
All these allow-lists ever do is create a barrier to entry so that the existing players can minimize the impact of newer players.
The way that registration makes sense is for DID Auth prior to issuing a VC, but I'm not seeing much in Tobias's comments to suggest that is the step he means.
> Furthermore, advocating for an exchange protocol where the wallet provider can
provide VCs, either issued by itself, an auditor, or a 3rd party, related to
the features it provides.
Its hard to really give feedback on this solution right now, as it feels very abstract, for instance:
- Where is the list of 3rd parties of auditors that a issuer trusts assertions to come from?
What auditors are you talking about? Why would an issuer trust anyone?
Each issuer is on the hook for doing their own onboarding and establishing the identity assurance necessary for their function. That's their own business logic and they are free to use whatever means they find appropriate. They will trust who they decide to trust and no outside entity should be necessary to tell them otherwise.
- How does a wallet know which 3rd parties or auditors the issuer trusts and therefore which to supply as a
"wallet feature" VC's.
Why does a wallet need to know any of this? All input and output to a wallet should be moderating by a human being. Potentially through established policies for automation, but deferring to a 3rd party is precisely the kind of centralization Manu is arguing against.
- How does a provider request such VCs?
What provider? A verifier asks for VCs using any of the many VC/VP Request protocols by talking with software that eventually reaches the Holder. Nobody else gets to ask for VCs. In fact, IMO, all VC/VP protocols SHOULD be user-initiated so that even verifiers only ever ask in response to a request from the Holder. Holders, IMO, should never expose a public endpoint for arbitrary VC requests.
If you're saying the issuer wants to also be a verifier, that's fine. But lets not conflate the two. Acting as an issuer has a different set of responsibilities than acting as a verifier.
- How does a wallet advertise which feature VCs it has to offer as features it supports?
It doesn't. That's a privacy problem. Verifiers ask for the type of VC they want. If the holder doesn't have it, an error message should propagate to the verifier so they can provide alternative options. For the holder to advertise its capabilities is asking for an increased attack surface. The Verifier should say what they need and the Holder should be free to satisfy those requirements using any system or software they decide. Just like websites and web browsers.
And what is a feature VC?
Wallets should work with any VC and DIDs whose crypto it can understand. If a wallet supports a given Verification Method, it should be able to support any VC using that method and any DID using that method. In practice, the number of methods are likely to follow the Rule of 3 and 4, within coherent market segments. https://www.bcg.com/publications/1976/business-unit-strategy-growth-rule-three-four
FWIW, I think digital identity is going to look more like the transportation industry than soft drinks, which means there will be 3/4 dynamics in particular segments like SUVs, sports cars, family cars, commuter cars, electric cars, etc.
So, yes, there will be allow-lists on differing methods, but to apply allow-lists to specific implementations of any particular component in any particular DID method is, IMO, not just a waste of time, it creates a false sense of security.
- Are complex things like a wallet provider passing something like a SOC2 audit even expressible in the form of a VC? Usually when a party is assessing another for compliance under a framework like SOC2 it requires them to actually read their auditors report, there is huge variability here around which controls/procedures a wallet provider may have been assess against also.
I can't comment on SOC2, but auditing holder software is a selection pressure for the holder, not the verifier or the issuer. As mentioned before, any such audits can be spoofed or hacked when checked interactively over the network. Such audits are great for individuals or enterprises when they select the software they want to use, but it is essentially meaningless for verifiers or issuers attempting to enforce the software they accept interactions with.
Also, anyone can say anything in a VC, so yeah, you could express the output of an SOC2 audit as a VC. Not sure what good it does you if you aren't the holder, because you can't guarantee that the software currently interacting is the subject of that VC. All you can do is prove that some software, somewhere, perhaps with a given binary (as could be verified by the holder) has been audited (and the audit results). That has nothing to do with whether or not the current system is running that binary.
> For example: "The private key that is being used for this exchange is secured
by a Hardware Security Module, and here is the digital proof provided by the
HSM vendor hardware".
In some cases this check may be sufficient, however in many others it may not. For example what happens if my wallet uses an HSM to store the keys but does absolutely no authentication on the party that is interacting with the wallet, hence anyone can generate a presentation for any VC it manages, what does an HSM backed key on its own offer in this instance?
If your wallet uses an HSM with crappy security, that's on you. You should have picked a more secure wallet. You can also leave your ignition keys in your car or even hardwire it so a key isn't necessary. I don't recommend it. Security assertions are for the "buyer" of that software. Not for third parties.
> We don't require that Google Chrome identify itself when you download your tax
forms, access your corporate bank accounts, or manage your family photos. Some
browsers, such as Brave, even go as far as lying about which browser they are
(and that's a good thing).
I don't agree with the comparison of wallets being akin to browsers and I think this is at the core of some of our disconnect.
It may be, but its extremely apt. You can't trust any client software to be what you imagine it could be. If you could solve this problem, you would solve DRM. The best you can do is create a horrible customer experience that at the end of the day will be trivially hackable by any script kiddie. The client can always be spoofed.
> However, if you frame the problem where the consent should actually happen (at
the wallet), then everything is fine. The wallet knows the party that is
asking for access (you can't ask for access to the wallet w/o saying who you are).
I think its a matter of opinion "where the consent should actually happen" and I'm personally not convinced this should be collected directly from the wallet.
IMO, the hardware wallet is THE place you need to be able to trust. That's it. Everything else is just a conduit for the math done on your HSM--even if that HSM is just software somewhere.
In general I think it can be dangerous to setup a consenting model, like you have suggested, where the party collecting the consent is the party that is granted the outcome produced by the consent being given. In this model malicious wallets have an incentive to just lie that they got consent from the End-User, so they can get the credential, issuers would be none the wiser.
Hmmm...
How is my wallet incentivized to falsify my consent?
That's seems like worrying about revolvers that are incentivized to misfire. Once it becomes known that a particular revolver has poor performance characteristics, people will stop buying it. Problem solved. Companies are always going to have varying quality in their products. Choose wisely.
If a wallet is compromised, you're screwed. Period. Trusting your wallet is fundamental to being able to trust anything in the system.
See Ben Laurie's article on this: https://authors.library.caltech.edu/72223/
We cannot remove trust completely, but we can abstract it away into just the one magic device that does the math with access to our secrets. Protect that. Secure that. Back that up. That's how you secure your crypto. If you don't care to be that secure, trust a service provider. That's also an option. But that service provider gets to be trusted on your behalf because they can do the math, not for any other reason. Coinbase isn't "allowed" to buy bitcoin for me because they have an approved software implementation. Thy are allowed to do it because I gave them money to buy bitcoin and put it into a transaction address that they control. They could take my BTC at any point, leaving me with only the courts to seek redress. It's an acceptable trade-off for many.
The way to support the Coinbases of the world is not by establishing wallet registration, it is by ensuring that it's the math that matters. That focus not only allows individuals and enterprises to set their own wallet custody policies if they choose to self-host that capability, it also ensures that this capability can be outsourced. This substitutability is how we get open systems through open standards. That is how email works. It is how the web works. It's how crypto works.
> To put it another way, it /is/ a general concern for the entire ecosystem...
but it's especially troubling for the current proposed OIDC4VC flows.
This is no more of an issue for an OIDC based flow, then it is for any other. Do we generally need to develop techniques that support a competitive issuer and wallet landscape for credentials, yes, does OIDC based protocols bias or limit these options in a negative way, IMO no. Therefore I don't feel this is a valid criticism w.r.t the original context in which this issue was raised, which is "Centralization dangers of applying OpenID Connect to wallets protocols".
I think Manu's point is spot on.
Those of us in the user-centric identity space saw this play out with OpenID 1.0. While initially created for self-sovereign style user control, it was immediately co-opted by major players who decided to be OpenID providers without being OpenID relying parties. We all watched as, before our very eyes, the democratizing tech we had helped birth became merely another surveillance tool for BigTech. Trying to protect people from the big players, in fact, gave the largest players even more reach into the every day web activities of just about everyone on the Internet. Login with Facebook isn't just a button. It's a beacon that tracks you on every website that offers it.
I can't speak to the specific features of OpenID that may or may not currently compromise the vision of VCs and DIDs, but I see, just in this thread, enough misunderstanding of what is actually technically possible to see exactly how "wallet registration" is a false hope that will engender centralized systems--those for which individual choice requires "jail breaking".
Let's not advocate for systems where user choice requires jail-breaking. Instead, let the math do the talking.
If the latest from OpenID suggests or requires wallet registration, then, yeah, we should avoid aligning ourselves with that part of OpenID.
Thanks,
[Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0>
Tobias Looker
MATTR
CTO
+64 (0) 27 378 0461
tobias.looker@mattr.global<mailto:tobias.looker@mattr.global>
[Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0>
[Mattr on LinkedIn]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D&reserved=0>
[Mattr on Twitter]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D&reserved=0>
[Mattr on Github]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D&reserved=0>
This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
________________________________
From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: 22 March 2022 12:33
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: W3C Credentials Community Group <public-credentials@w3.org>
Subject: Re: Centralization dangers of applying OpenID Connect to wallets protocols (was: Re: 2022-2026 Verifiable Data Standards Roadmap [DRAFT])
EXTERNAL EMAIL: This email originated outside of our organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe.
On Fri, 18 Mar 2022 at 17:49, Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:
I'm taking all of my hats off and saying the rest as a "concerned citizen and
computer scientist". Take it as personal commentary, for whatever that is worth.
I expect much of this to be controversial... and result in an unavoidable
permathread. :)
TL;DR: It is hopelessly naive to think that OpenID Connect, THE protocol that
centralized social login to 3-4 major tech companies, only requires "small
changes" for self-sovereign identity and is a "doorway" we should gleefully
step through.
On 3/17/22 5:45 PM, Kaliya Identity Woman wrote:
> Yes - and I agree with the note following this one on the thread that they
> are meeting different needs use-cases.
It's all a matter of perspective, isn't it? :)
When you get down into the details, sure you can argue that some protocols are
addressing different needs/use-cases, but it is also undeniable that every
single one of the protocols can move a Verifiable Credential from point A to
point B. In that way, they're directly competitive with one another. That's
not an interesting debate, though; it's at the wrong level -- too meta.
What would be more beneficial is for someone to produce a pros/cons matrix
like we did for "Protecting VCs using pure JSON JWTs vs. VC-JWTs vs. Linked
Data Proofs":
https://w3c.github.io/vc-imp-guide/#benefits-of-jwts
https://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs
Until we get to that level of detail, I expect we'll not make much progress on
the wallet protocols topic.
> The fact is that there is a huge opportunity to really leverage the "OIDC"
> "doorways" that exist all over the web (a protocol that is literally used
> a billion times a day...you know some real adoption) to exchange VCs - with
> some small changes.
>
> AND people in this group seem to be "deathly afraid" of that work because
> it isn't home grown here alone in isolation and focused on web only.
I... just... don't even know where to start. I disagree with every concept in
the previous paragraph. :)
I can't speak for anyone else in this group, so I'll just speak for myself:
It is hopelessly naive to think that OpenID Connect, THE protocol that
centralized social login to 3-4 major tech companies, only requires "small
changes" for self-sovereign identity and is a "doorway" we should gleefully
step through.
Login with Google/Facebook/Apple/Microsoft, those "billions of times a day"
usages... are all coerced logins. We have no choice but to use the big tech
vendors. That is not a world I want to contribute to.
We are not "focused on web only" here... though it is an effective "gotcha!"
talking point that seems to not be questioned when uttered ("I mean... the
word "WEB" is in World Wide Web Consortium! What else could they be up to over
there!?"). The phrase is disingenuous, I really wish those uttering it would
stop... but you can't blame them, it's an effective way to get people who
don't know any better nodding in agreement with whatever "non-Web" thing
you're going to say next.
I am "deathly afraid" of the work, because people are rushing into it without
thinking deeply about the consequences. So, "Nope!":
I refuse to just go with the herd and gleefully re-cement centralization in
this new generation of identity technologies.
I refuse to trust that things will be different this time because the same
people that created OpenID Connect have learned their lessons and are doing
things differently now.
... and I refuse to accept your mischaracterization of this community, the
good faith efforts that they've put forward to coordinate where they can, or
why some of us remain sceptical of some of the other wallet protocol efforts
going on right now.
It is possible for all of us, across all communities, to act in good faith and
still disagree on the path forward.
I certainly don't think for a second that the vast majority of people involved
in OpenID, DIF, CCG, IIW, or RWoT are acting in bad faith. Misguided, possibly
(including myself!), but not this "Not Invented Here Tribalism" narrative that
seems to be so popular. I see a bunch of people, across each "silo", doing
their best to solve hard problems given all of the pressures of their work and
home life. Full stop.
Going back to OpenID being applied to Verifiable Credential Exchange. There
are three fatal flaws that need to be overcome for it to be a good idea:
1. Eliminate registration -- if you require wallet
registration, you enable centralization.
2. Eliminate NASCAR screens; don't allow verifiers to
pick/choose which wallets they accept. If you allow
either of these things to happen, you enable
centralization.
3. Eliminate the concept of "App Store"-like in-wallet
"Marketplaces". If you do this, you put issuers at a
natural disadvantage -- pay to play to get listed
in a wallet's "Marketplace".
Rather than seeing solutions proposed to the problems above, the OpenID
specifications seem to be doubling down on enabling the three items above.
Out of CHAPI, DIDCommv2, and OpenID... OpenID is the most centralizing, worst
solution for Verifiable Credential Exchange on the table today.
That is not to say it can't be fixed, but I have yet to see a proposal that
addresses all three items above.
> There is a lot of "othering" of work that isn't CCG. Because that work is
> less "pure".
No, there are concerns related to the technical underpinnings of OpenID that
lead to centralization that have yet to be addressed by the current proposals.
The only Othering I'm seeing going on here is what you're doing. Casting some
vague subset of the CCG as this irrational, web-only, not invented here,
tribal silo and going after community volunteers that are not doing what you
want or meeting on your schedule.
I've known you for many years, Kaliya -- you're better than this and are
usually a bridge builder and tireless advocate for open lines of
communication. I know you're frustrated, we all are, but I don't think the way
in which you've chosen to engage is going to result in what you want.
Again, just my $0.02 as a community member.
+1 agree with everything Manu said
As the old saying goes, "no matter how decentralized you make something, centralization creeps in through the back door". From my experience OIDC is a vector for that, perhaps the biggest vector
I recall being on a call with Manu, 15 years ago, where we were advocating a web based single sign-on solution based on PKI that his team had put together and worked in the browser. We came quite close to getting that into Ubuntu, but it was felt that browser support wasnt quite there
Over the course of the next decade, that solution, or something similar, became the basis of the Solid project. Single sign on via PKI was the the genesis and value proposition of what we created. It was innovative because users owned their own profiles, they could manage their own keys, and could log in without the need to rely on a trusted third party. One slight weakness was that it was domain based, and hard to move your identity. Content addressable identifiers such as DID provide an innovative (and complementary) alternative to that
Much later OIDC was added to solid, and it was promised that it could live "side by side" with PKI. That was not the case, as soon as OICD was allowed in, the trusted third party system took over and owning your own keys got broken and never fixed. Tests were commented out etc. There was also no greater source of bugs in Solid than OIDC. They were never fixed. People came to the project and left, the earth being salted with the disappointment, as it appeared to be something that didnt work. In contrast, I used PKI on an hourly basis for 10 years (in browser, apps and server to server), and it never failed me.
You may recall the original OpenID (nee. Yadis) from bradfitz was designed for sovereign identity. But increasingly it became used for just certain large providers, creating the NASCAR problem, and occasionally you would have "Log in with your OpenID". Which often didnt work. Then Yahoo came along and started white listing, and sovereign ID didnt get a look in.
It's the same story again and again. We need to stand up for PKI solutions. Because trusted third party solutions will never be content to live side by side. They are a vector for the biggest companies to get bigger and leverage their overwhelming competitive advantages through standards
It's a permathread because trusted third parties will never stop trying to get into standards and making themselves those trusted third parties. That's OK, we should accept that, but also create more choice for the user with modern cryptographic solutions
-- manu
--
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/
--
Joe Andrieu, PMP joe@legreq.com<mailto:joe@legreq.com>
LEGENDARY REQUIREMENTS +1(805)705-8651
Do what matters. http://legreq.com<http://www.legendaryrequirements.com>
This email and any attachments are for the sole use of the intended recipients and may be privileged, confidential or otherwise exempt from disclosure under law. Any distribution, printing or other use by anyone other than the intended recipient is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and its attachments.
Received on Tuesday, 22 March 2022 18:58:01 UTC