6 ms·

I agree that CBOR is unnecessarily shoe horned into the spec, but it honestly isn't that bad. IMO there are two other problems that need to be resolved for weba

by pg_bot 4y ago

I agree that CBOR is unnecessarily shoe horned into the spec, but it honestly isn't that bad. IMO there are two other problems that need to be resolved for webauthn to go mainstream. The first is the fact that there is no mechanism for changing/updating the url tied to a device for a website. This is intentional for phishing reasons, but if you want to rebrand or are acquired you're going to run into problems. The second is the frontend JS API is a bit awkward to implement.

tialaramex 4y ago
> The first is the fact that there is no mechanism for changing/updating the url tied to a device for a website. This is intentional for phishing reasons, but if you want to rebrand or are acquired you're going to run into problems. You can't solve this "problem". The RPID is bound into the actual credentials, it isn't that there's no mechanism provided to change it, but rather that it is part of the credentials themselves. If you want actionable advice for people whose big boss has determined that they absolutely must change from foo.example to bar.example, they need to use the foo.example site to accept the credentials and forward users to bar.example and then re-enrol them to the "new" bar.example account with new credentials. Users will probably be annoyed about this hassle, but you can't do anything about that it was sealed in with the decision to get rid of foo.example. If your feedback is "But that's user hostile" yeah, so, don't change from foo.example to bar.example. What seems so very important to you is just another pointless annoyance for your users. Remember, you don't need to put the foo.example name on employee badges or the corporate logo to keep it, you only need to keep the name and use it to do the auth step. The same "Re-brand at all costs" thinking destroys users bookmarks, email address books, word-of-mouth, - destroys so much intangible value, and yet you can bet that the executives who decided upon it will argue that since they didn't measure that value they're destroying it doesn't exist.

by pg_bot 4y ago

tialaramex 4y ago

> The first is the fact that there is no mechanism for changing/updating the url tied to a device for a website. This is intentional for phishing reasons, but if you want to rebrand or are acquired you're going to run into problems. You can't solve this "problem". The RPID is bound into the actual credentials, it isn't that there's no mechanism provided to change it, but rather that it is part of the credentials themselves. If you want actionable advice for people whose big boss has determined that they absolutely must change from foo.example to bar.example, they need to use the foo.example site to accept the credentials and forward users to bar.example and then re-enrol them to the "new" bar.example account with new credentials. Users will probably be annoyed about this hassle, but you can't do anything about that it was sealed in with the decision to get rid of foo.example. If your feedback is "But that's user hostile" yeah, so, don't change from foo.example to bar.example. What seems so very important to you is just another pointless annoyance for your users. Remember, you don't need to put the foo.example name on employee badges or the corporate logo to keep it, you only need to keep the name and use it to do the auth step. The same "Re-brand at all costs" thinking destroys users bookmarks, email address books, word-of-mouth, - destroys so much intangible value, and yet you can bet that the executives who decided upon it will argue that since they didn't measure that value they're destroying it doesn't exist.