Include supported extensions in getClientCapabilities.

[agl]

It is of somewhat limited value because getClientCapabilities can't know what extensions the user's authenticator will support, but it can be meaningful to know that an extension isn't supported. Absent this, sites are guessing based on browser names and versions, but that is fragile.

---

Preview | Diff

[Kieun]

It took five years since I brought this requirement.

[emlun]

I'm considering whether clients should also be allowed to set false for extensions that are known and not supported, to give RPs a definitive answer in those cases. That would probably include the extensions defined inline in the spec, but probably not many extensions defined elsewhere. But maybe that makes for too much variation? I'm not sure, this is probably fine either way.

[g-davidson]

This looks great!

[msft-bob]

Looks good. Thanks for putting this together.

[nsatragno]

Are we concerned that there will be a gap until we get the browsers updated where extensions will be supported, but this capability will not. Are we risking those RPs assuming the extension is not supported when it is during that gap?

(same comment as in #2051)

[emlun]

Both the method and the extension: capabilities are added in L3, so formally speaking there cannot be any mature implementation of getClientCapabilities() that does not include the extension: capabilities. At least in my opinion, any current implementations of getClientCapabilities() should be considered experimental from a spec point of view until L3 reaches at least CR maturity. So no, I don't think we should worry about a gap like that, because RPs should not be relying on these features yet.