3 ms·

As others have said, the main problem is that 1) There is too much flexibility which means that "name" might be "firstname" or "first_name" somewhere, which is

As others have said, the main problem is that 1) There is too much flexibility which means that "name" might be "firstname" or "first_name" somewhere, which is why you need so many different implementations and 2) It is very hard to distill the relevant parts from the spec which covers all parts with equal vigour! We have the same issue with the UK Wiring Regulations, so they produced an "On Site Guide", which covers only the main parts of the main regulations and is about 10th the size. The same could be true of the OAuth spec. To be fair, OpenId Connect partially addressed both issues by taking a subset of the spec (when used for authentication) and then nailed down what the properties should be and what encryption mechanisms are required to be implemented.

jeroenhd 3y ago
> 1) There is too much flexibility which means that "name" might be "firstname" or "first_name" somewhere, which is why you need so many different implementations Names are funny because many implementations of standards make the mistake of presuming there's such a thing as a "first name" and a "last name" that make up a name. Or that the "last name" is the part you pass down to your family, and so on. If I see "first name" in any spec, I assume the spec is written solely for a small subsection of the population by someone who didn't put all that much thought into the spec. Not every service needs an email address, there's no telling what a valid username may look like, address specifications are basically plaintext strings even though many services pretend there's structure to them, and so on. Hell, most APIs authenticating against OAuth don't even need a username or user ID to function, all they need to provide is an access token. Most fields have no business being standardised because they cannot be. OAuth is not a "log in with Facebook" standard, just like IPv4 isn't an "access Wikipedia" standard. If you host something that people authenticate through OAuth yet, you inevitably need to provide some kind of custom service properties.

jeroenhd 3y ago

> 1) There is too much flexibility which means that "name" might be "firstname" or "first_name" somewhere, which is why you need so many different implementations Names are funny because many implementations of standards make the mistake of presuming there's such a thing as a "first name" and a "last name" that make up a name. Or that the "last name" is the part you pass down to your family, and so on. If I see "first name" in any spec, I assume the spec is written solely for a small subsection of the population by someone who didn't put all that much thought into the spec. Not every service needs an email address, there's no telling what a valid username may look like, address specifications are basically plaintext strings even though many services pretend there's structure to them, and so on. Hell, most APIs authenticating against OAuth don't even need a username or user ID to function, all they need to provide is an access token. Most fields have no business being standardised because they cannot be. OAuth is not a "log in with Facebook" standard, just like IPv4 isn't an "access Wikipedia" standard. If you host something that people authenticate through OAuth yet, you inevitably need to provide some kind of custom service properties.