Emil Lundberg

@bornio See PR #1663.

The short answer is that you should set `pubKeyCredParams` to include all algorithms whose verification procedure you support. But that of course leaves the question of what's the minimal set...

@MasterKale by `-256`, did you mean `-7` (P-256)? I think (4) [`pubKeyCredParams`](https://w3c.github.io/webauthn/#dom-publickeycredentialcreationoptions-pubkeycredparams) is the most appropriate place to put this guidance. I agree that's where an RP dev is most...

I don't think any multi-party transaction has been proposed here. The proposal is not to allow site A (merchant) to register credentials on behalf of site B (payment provider), rather...

Obsoleted by PR #1607.

Here's the draft of our recovery extension idea presented at W3C TPAC today. I apologize for omitting the cryptograpy details until we've had them properly vetted. Pseudo-spec draft: https://gist.github.com/emlun/74a4d8bf53fd760a5c5408b418875e2b Slides...

@watahani We don't want to publish the crypto details just yet - I don't think we'll keep it secret, but we also don't want to risk people starting to use...

Today at the face-to-face meeting in Fukuoka we presented our recovery extension in full, including all details of the key agreement scheme. The extension draft is published here: https://github.com/Yubico/webauthn-recovery-extension This...

Today we also found some prior work proposing the same key agreement scheme: the ISAP protocol described in [this article](https://hackernoon.com/blockchain-privacy-enhancing-technology-series-stealth-address-i-c8a3eb4e4e43), which references [this whitepaper](https://cryptonote.org/whitepaper.pdf). We haven't yet found any proof...

>`S` must be kept secret, otherwise collaborating RPs can forge an otherwise valid credential id and test whether a user holds the corresponding private key, which uniquely identifies the user....