Add uaf attestation format

[rlin1]

---

Preview | Diff

[jyasskin]

Nothing against this particular attestation format, but there are getting to be a lot of attestation formats that RPs have to implement. Is there any way to limit the number of formats?

[rlin1]

There exist some (relevant) classes of authenticator models in the market. I propose to support the most important ones.
In the end the RP will decide which ones to accept.

[selfissued]

Per my review of PR #407 , we should do what it takes to make it be possible to add the UAF credential type and attestation format in a separate document, rather than requiring that they be added to the WebAuthn spec. That's the approach that I think we should pursue for this one and PR #407 . With adequate registry support, every additional algorithm, etc. need not be continually added to the WebAuthn spec itself.

[equalsJeffH]

@selfissued proposed:

Per my review of PR #407 , we should do what it takes to make it be possible to add the UAF credential type and attestation format in a separate document, rather than requiring that they be added to the WebAuthn spec. That's the approach that I think we should pursue for this one and PR #407 . With adequate registry support, every additional algorithm, etc. need not be continually added to the WebAuthn spec itself.

While I agree with adding registry support for WebAuthn signature-and-assertion-formats (see #296, #233), I disagree with not merging #407 and #408 in this specific case of UAF because:

1. there are millions of already-deployed UAF-capable smartphones, which are upgradeable to speak CTAP and thus be usable with WebAuthn-enabled browsers via CTAP (in the nearish term), and,
2. the amount of normative spec prose to enable handling UAF signature and assertion format is small, and largely consists of changes we will need to introduce anyway in order to prepare the webauthn spec to properly leverage a "signature and assertion format registry". Essentially the webauthn spec will just reference the UAF spec set for the bulk of the normative details.
3. we have updated the webauthn spec already to handle U2F authenticators for essentially the same reasons.

If someone later desires to register and have WebAuthn support yet another signature-and-assertion-format, then I agree that the approach they should take is to formally register such and specify it in self-contained specs separate from the present WebAuthn spec.

This PR is concise, largely does not affect other portions of the webauthn spec, incorporates some changes that we will need to do any way in order to have the spec properly handle separately-defined assertion-and-signature-formats.

We ought to refine this PR and #407 appropriately and merge them for WD-06.

Fixes #465

[leshi]

Please resolve the discussion in #554 before merging.

[nadalin]

Per 03/07/19 F2F Close