W3C home > Mailing lists > Public > public-webauthn@w3.org > May 2017

Re: PR #407 Add credential type uaf

From: =JeffH <Jeff.Hodges@KingsMountain.com>
Date: Wed, 17 May 2017 14:25:35 -0700
To: W3C Web Authn WG <public-webauthn@w3.org>
Message-ID: <cd3cedf2-d7b7-5947-f6fb-e6968763583b@KingsMountain.com>
[this comment 
<https://github.com/w3c/webauthn/pull/407#issuecomment-302148967> was 
not auto-fwd'd to list, so posting directly]

wrt PR #407 "Add credential type uaf"
<https://github.com/w3c/webauthn/pull/407> and @selfissued's (Mike 
Jones) comment 
<https://github.com/w3c/webauthn/pull/407#pullrequestreview-38270421> on it:

@selfissued wrote:
 > If we're going to be adding credential types, then it seems like we
 > should probably add a Credential Types registry to our registry
 > document. Do you agree with this, @equalsJeffH ?

Yes.  Though, it ought to be called a "signature and assertion format 
registry", see #296 [1]

@jyasskin asked:
 > What does it mean to add a credential type instead of just adding
 > a new attestation format?

"credential type" is a misnomer, it really should be named something 
like "assertionAndSignatureFormat" -- see #296 and #233 [1]

@selfissued proposed:
 > it should 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 #408 [2]

I disagree /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 near-ish 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. And,

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 

We ought to refine this PR and #408 [2] appropriately and merge them for 

[1] https://github.com/w3c/webauthn/issues/296

[2] https://github.com/w3c/webauthn/pull/408
Received on Wednesday, 17 May 2017 21:39:32 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:26 UTC