CREDENTIAL: boolean acceptPasswords = true;

[annevk]

Boolean arguments should not default to true.

[annevk]

Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28477 to track this at the IDL level.

[mikewest]

Why would excludePasswords = false be better? Double-negatives seem more difficult to understand than negated positives.

[annevk]

If some boolean arguments default to false and others to true, you have to study each method to know when you can omit the argument. I think JavaScript and the platform quite consistently defaults to false (XMLHttpRequest is super confusing due to it behaving differently). Also, the common case would be excludePasswords = true which does not seem hard to understand.

However, you could also make it accept an enum. passwords = "exclude".

[mikewest]

The underlying question is how to support extensibility. Right now we have Local and Federated credentials. Assume we have MoonVector credentials in the future that use your precise distance and direction from Earth's moon to determine who you are (did you know that each individual has a distinct vector from the moon? AMAZING.). Most websites won't accept this amazing new form of authentication at first, but someday they might only accept this form.

Since we already have federations as a clear control on FederatedCredential, I wanted something similar for LocalCredential. Perhaps it would be siimpler to give a list of acceptable types, defaulting to everything the UA knows about?

[annevk]

Yeah that might be better since the whole setup assumes the user agent is going to be the middle man anyway.

[domenic]

+1 on boolean arguments defaulting to false.

List of acceptable types seems reasonable as well, although unsure whether it's better to create a string mapping (accept: ["federated", "local"]) or use the types directly (accept: [FederatedCredential, LocalCredential]).

LOL @ moon vectors ^_^

[mikewest]

I'm going to trivially resolve this by inverting the meaning of the boolean, and deal with the extensibility question as part of #256, which has substantial overlap with @domenic's accept proposal.