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

RE: [webauthn] Plumb User ID through

From: Johan Verrept <Johan.Verrept@vasco.com>
Date: Sun, 24 Sep 2017 19:57:15 +0000
To: John Bradley <jbradley@yubico.com>, Jakob Ehrensvard <jakob@yubico.com>
CC: W3C WebAuthn WG <public-webauthn@w3.org>
Message-ID: <baedd91fc28a48ee872f07fc18a29809@srv-be-exch.vasco.com>
Let's be clear, I am not advocating using a 1-byte credential ID, on the contrary.

I am merely pointing out that the specification is assuming that Credential IDs are unique while there is no way to actually enforce that nor does it define a way for RPs to deal with duplicate Credential IDs. Either Credential IDs are guaranteed globally unique and the spec provides a way to achieve that or RPs must have a way to deal with collisions.

I would like to see some requirements on the Credential ID to qualify "globally unique"  and an explicit way for RPs to deal with collisions.

	J.
 

-----Original Message-----
From: John Bradley [mailto:jbradley@yubico.com] 
Sent: Friday, 22 September, 2017 19:09
To: Jakob Ehrensvard <jakob@yubico.com>
Cc: Johan Verrept via GitHub <sysbot+gh@w3.org>; W3C WebAuthn WG <public-webauthn@w3.org>
Subject: Re: [webauthn] Plumb User ID through

I think that is the correct thing to do.

I think the concern is that other devices may try and scope the credential id to the user_id or the token during make credential.

If they produce credential id that are from 1 to x then anyone who tries to create a global index for credential id is going to be stuffed.

It seems to me that any authenticator that is not attempting to create a globally unique credential id should be considered broken.

If we are having RP reject duplicate credential_id then we should be sure that a new credential_id/key is generated for each new make credential.   Otherwise the user will be stuck in the unlikely event of a collision.

John B.
> On Sep 21, 2017, at 3:11 PM, Jakob Ehrensvärd <jakob@yubico.com> wrote:
> 
>> Credential IDs are not guaranteed unique in any way. Unless I missed 
>> something in the specs, it is perfectly valid to store all data 
>> locally and return a single byte key index.
> 
> Then, I believe I've missed something important here. The credential 
> ID must be a unique identifier, just like the U2F key handle. We make 
> the CTAP2 credential ID equal to the U2F key handle, so a U2F 
> credential can be used with WebAuthN and vice-versa.
> 
> For resident credentials, we generate a credential ID from the public 
> key, making this a 128-bit identifier.
> 
> Did I ge this wrong ?
> 
> 


Received on Sunday, 24 September 2017 19:57:41 UTC

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