Adam Langley

> But, how can we distinguish that the credential is coming from the platform authenticator or from the roaming authenticator The `authenticatorAttachment` value in the [resulting object](https://w3c.github.io/webauthn/#iface-pkcredential) will tell you...

> One thing to note is that the authenticatorAttachment in the create() and get() response is nullable. > Sometimes the RP might not get any value from the response. I...

> If it is the case, then the value should not be null in the new version of the spec? For old browser cases, the attribute itself does not exist...

From the call of 2021-01-06, the group doesn't believe that a change should be made here. Browsers do not always know the transports supported by an authenticator. Making the transports...

We punted this to level three (i.e. a future version): The history is that JOSE started out fully specifying signature algorithms (i.e. JOSE defines ES256 as “ECDSA using P-256 and...

Comments from narrow to wider: #### AAGUID transmission Doesn't seem necessary to leak this to RPs? RP learn and, if they demand, can judge attestation for recovery authenticators when a...

> Transmitting the AAGUID early (although unsigned) allows the RP to fail faster and prevent the user from inadvertently getting locked out. I don't believe that we would want to...

> If you have a single Authenticator, how can you be sure that there isn't a clone of it somewhere that you don't know about? Supply-chain issues exist whether or...

A unique encoding should be expected here since the context is quite bespoke: a single binary field, stored on limited external hardware that can truncate the string at an arbitrary...

Thanks for that and sorry for the delay—I've been on vacation. I think we want a truncation indicator so that we know when to disregard the trailing metadata. If the...