Comment by shiftingleft | Hacker News Reader

Comment by shiftingleft | Hacker News Reader

"Mozilla:

    The DID Core spec has not demonstrated any degree of practical interoperability, instead delegating that to a registry of 50+ methods.

    The DID architectural approach appears to encourage divergence rather than convergence & interoperability. The presence of 50+ entries in the registry, without any actual interoperability, seems to imply that there are greater incentives to introduce a new method, than to attempt to interoperate with any one of a number of growing existing methods.

    The lack of restrictions on the registry are allowing methods diametrically opposed to the principles of the group & spec, and methods which are actively globally harmful to sustainability.

    [W]e believe the DID specification may not be fixable (MUST NOT become a Recommendation)."

"The Director concludes that the balance lies in favor of the DID developer community, encouraging it to continue its work and search for consensus on standard DID methods. The objections are overruled."

Where have I heard this before? https://www.wired.com/2012/07/developer-quits-oauth-2-0-spec...

For those of us who aren't webdevs, what was the final fate of OAuth 2.0?

It's very widely used. Most SSO providers are using it, including the biggest ones.

Although personally i don't think its a great spec. Its a good enough spec (certainly better than saml, shudder) - "good" is not the same as works acceptably or popular.

After extensive experience with SAML and other specs, I don't think it's better than SAML in a fundamental way. It's certainly better in that it doesn't require a mind-numbingly verbose blob of XML, but strip away the XML and all that verbosity, and you basically end up with... kerberos.

OAuth 2.0 basically killed generic identity providers leaving us with a hand full of SSO providers you can use.

It also instead of a simple generic OAuth 2.0 library we had (and still have) separate libraries for the various OAuth SSO providers. Through this has converged a bit since the initial days. But the initial days where enough to cause harm to the ecosystem.

It also needs a variety of "extensions" you have to add to make it secure. But which can slightly differ between SSO providers. (Note sure but I thing some of this "extensions" have been added to the spec retrospectively.)

In conclusion I would say while OAuth 2.0 is widely used it also was widely harmful and lead to a further centralization and to users being more dependent on a few mega corporations.

In this context it has fully failed some of the initial ideas people had about it when it's design started.

Just because something is widely used doesn't mean it's not harmful or well designed. Adaptation of technology is often not driven by what is the technological best solution especially wrt. web technology.

You may have heard the aphorism, "All problems in computer science can be solved by another level of indirection." This, or some variation of it, is known as the fundamental theorem of software engineering, variously attributed to Andrew Koenig, Butler Lampson, and David J. Wheeler.

With oauth2, literally any sort of authorization (or, in theory, authentication) is possible, but first you have to ask some endpoint for the details. In the case of oauth2, the core concept for authorization is "scope", but nothing is prescribed in scopes. They can literally be anything the auth provider describes. In theory, it's not supposed to matter – a consumer is just supposed to be able to pass around scopes from providers and let them determine if access is allowed. In practice, there's no practical way to reason about scope+resource permssions.

Oh, and despite the name, oauth2 is not about authentication, it's only about authorization. The OIDC spec, built on oauth2, provides authentication services, but again, there's no spec. Every auth provider does what it wants.

It's sometimes said that oauth2 is great for consultants, because any organization wanting to deal with it must hire (or contract with) specialist who can sort out the ill-defined problem space.

> despite the name, oauth2 is not about authentication, it's only about authorization

OAuth is short for Authorization in the first place.

https://datatracker.ietf.org/doc/html/rfc6749

What a brilliant and unambiguous abbreviation!

Because this is my specialty, I long ago learned to specify either authn or authz. The OAuth spec should have been the OAuthz spec.

Agree, or could be OAF just like the way GNAP named itself.

Btw, I'm relatively new to this field. Didn't the terms like authn/authz exist at the time they named OAuth? Or any other reason not to use them?

Reply on news.ycombinator.com