5 ms·

I don’t understand the point of having a specification when 2 out of the 3 major browsers have objected. Who will implement it? Why bother with this?

by teg4n_ 4y ago

fabrice_d 4y ago
The W3C doesn't produce only browser-related specifications. Service providers will implement, eg. instead of login with a user/password they will support some the DID methods. I would say that the process worked as intended. There was disagreement among members, things got discussed (see https://www.w3.org/2022/03/did-fo-report.html https://www.w3.org/2022/03/did-fo-report.html for details) and a decision was made according to the W3C process. All good!
- WkndTriathlete 4y ago
  Having read through the abstract and the first example of the specification I'm highly skeptical that the W3C process worked to produce something that is actually useful, in the sense that it ends up widely used. DID kind of strikes me as ASN.1 "with crypto/distributed ledger" stuff tacked on top of it.
topspin 4y ago
Because expecting standardization of DID methods at this point is unreasonable. A premature attempt to standardize DID methods would be both futile and likely harmful. It's futile because the future universe of DID methods can't be anticipated now, so whatever wrong set of DID methods W3 promulgated would include both poor choices and omit good choices. It's harmful because whatever future methods might emerge will relegated to a second class for having failed to 'get in' on the initial standard. Better to avoid prematurely enshrining some arbitrary set of methods and allow a consensus to emerge via practice and exposure. At some point, as the inevitable shake-out of bad ideas and nefarious actors occurs, DID methods can be standardized in a useful way. Yes, the lack of a simple list of SHALLs will impede the immediate adoption of DID for all conceivable purposes, but better that struggle than the next to impossible task of loosening the grip of beneficial parties that have a standards document to wave around. It's almost like they've learned something over the last quarter century.
- cratermoon 4y ago
  > It's futile because the future universe of DID methods can't be anticipated now, so whatever wrong set of DID methods W3 promulgated would include both poor choices and omit good choices Or maybe it's just too soon to try to carve a "standard" into the w3c process stone. A half-baked protocol is worse than no protocol at all.
  - asimpletune 4y ago
    > A half-baked protocol is worse than no protocol at all. I think the literal opposite is true, no?
    - SahAssar 4y ago
      If there is no protocol nobody expects interoperability. If there is a half-baked protocol everyone expects interoperability but it never works as it should.
      - cratermoon 4y ago
        > never works as it should. Not only that, by exploiting ambiguities and gaps, protocols can be made to work as they shouldn't. At least that keeps the security consultants in business.
- DannyBee 4y ago
  If you have literally no idea what a good or bad answer even looks like, it's not time to standardize it at this sort of formal level yet. Beyond that, some of this is just odd. " It's harmful because whatever future methods might emerge will relegated to a second class for having failed to 'get in' on the initial standard." Good. We can deal with that in v2.0. Trying to design this kind of thing to anticipate every possible future good thing that might come along is a folly. If you can't standardize them yet because you don't even know, then i go back to the first sentence i wrote :) Beyond that, your optimism in what will happen (shakeout of bad ideas and then harmonious replacement with standards) seems ... mostly misplaced. Assume it takes off - what will instead happen is that you will be stuck supporting tons of non-standard methods developed between now and when anyone standardizes them forever. It will likely hamstring your future development as well. I cite as evidence - literally the history of everything :) There was 100% no reason to standardize this now other than wanting to feel good about themselves. It isn't needed to push forward. It should have waited until someone had any idea what good looks like.
dmitriid 4y ago
> I don’t understand the point of having a specification when 2 out of the 3 major browsers have objected. That's how standard bodies are supposed to work: by finding consensus. If there are many objections, the spec should be adjusted until people agree. However, if you have enough clout, you can try and still ram it through. See hardware APIs. 2 out of 3 major browsers have objected.

I don’t understand the point of having a specification when 2 out of the 3 major browsers have objected. Who will implement it? Why bother with this?

by teg4n_ 4y ago

I don’t understand the point of having a specification when 2 out of the 3 major browsers have objected. Who will implement it? Why bother with this?

fabrice_d 4y ago

The W3C doesn't produce only browser-related specifications. Service providers will implement, eg. instead of login with a user/password they will support some the DID methods. I would say that the process worked as intended. There was disagreement among members, things got discussed (see https://www.w3.org/2022/03/did-fo-report.html https://www.w3.org/2022/03/did-fo-report.html for details) and a decision was made according to the W3C process. All good!

WkndTriathlete 4y ago
Having read through the abstract and the first example of the specification I'm highly skeptical that the W3C process worked to produce something that is actually useful, in the sense that it ends up widely used. DID kind of strikes me as ASN.1 "with crypto/distributed ledger" stuff tacked on top of it.

topspin 4y ago

Because expecting standardization of DID methods at this point is unreasonable. A premature attempt to standardize DID methods would be both futile and likely harmful. It's futile because the future universe of DID methods can't be anticipated now, so whatever wrong set of DID methods W3 promulgated would include both poor choices and omit good choices. It's harmful because whatever future methods might emerge will relegated to a second class for having failed to 'get in' on the initial standard. Better to avoid prematurely enshrining some arbitrary set of methods and allow a consensus to emerge via practice and exposure. At some point, as the inevitable shake-out of bad ideas and nefarious actors occurs, DID methods can be standardized in a useful way. Yes, the lack of a simple list of SHALLs will impede the immediate adoption of DID for all conceivable purposes, but better that struggle than the next to impossible task of loosening the grip of beneficial parties that have a standards document to wave around. It's almost like they've learned something over the last quarter century.

cratermoon 4y ago
> It's futile because the future universe of DID methods can't be anticipated now, so whatever wrong set of DID methods W3 promulgated would include both poor choices and omit good choices Or maybe it's just too soon to try to carve a "standard" into the w3c process stone. A half-baked protocol is worse than no protocol at all.
- asimpletune 4y ago
  > A half-baked protocol is worse than no protocol at all. I think the literal opposite is true, no?
  - SahAssar 4y ago
    If there is no protocol nobody expects interoperability. If there is a half-baked protocol everyone expects interoperability but it never works as it should.
    - cratermoon 4y ago
      > never works as it should. Not only that, by exploiting ambiguities and gaps, protocols can be made to work as they shouldn't. At least that keeps the security consultants in business.
DannyBee 4y ago
If you have literally no idea what a good or bad answer even looks like, it's not time to standardize it at this sort of formal level yet. Beyond that, some of this is just odd. " It's harmful because whatever future methods might emerge will relegated to a second class for having failed to 'get in' on the initial standard." Good. We can deal with that in v2.0. Trying to design this kind of thing to anticipate every possible future good thing that might come along is a folly. If you can't standardize them yet because you don't even know, then i go back to the first sentence i wrote :) Beyond that, your optimism in what will happen (shakeout of bad ideas and then harmonious replacement with standards) seems ... mostly misplaced. Assume it takes off - what will instead happen is that you will be stuck supporting tons of non-standard methods developed between now and when anyone standardizes them forever. It will likely hamstring your future development as well. I cite as evidence - literally the history of everything :) There was 100% no reason to standardize this now other than wanting to feel good about themselves. It isn't needed to push forward. It should have waited until someone had any idea what good looks like.

dmitriid 4y ago

> I don’t understand the point of having a specification when 2 out of the 3 major browsers have objected. That's how standard bodies are supposed to work: by finding consensus. If there are many objections, the spec should be adjusted until people agree. However, if you have enough clout, you can try and still ram it through. See hardware APIs. 2 out of 3 major browsers have objected.