Clarify usage of credentialRecord.transports

[jameshartig]

Proposed Change

The current spec says that credentialRecord.transports is RECOMMENDED but I can't find a reference for when to use it. I believe this was lost in https://github.com/w3c/webauthn/pull/1773 where it was previously used to populate the allowCredentials.

I would like to understand how RPs should use this field in practice. We (an RP) require the use of discoverable credentials and therefore never fill in allowCredentials. My understanding is that credentialRecord.transports has no purpose in our use-case. I don't know how the WG decides between "RECOMMENDED" and "OPTIONAL" but it's confusing that it's currently "RECOMMENDED" without any mention of how/when to use it.

Also, I wasn't sure where to post this question, I didn't see much non-GitHub communication in the public mailing list and my company is not a W3C member. If this is the wrong avenue for this type of discussion, I apologize.

[sbweeden]

The right place to ask this question is the fido-dev mailing list: https://groups.google.com/a/fidoalliance.org/g/fido-dev

If you are only using empty allowCredentials then you don't need to store it. It has a purpose though - when passed back to the client (browser) when using an allowCredentials list, it allows the browser to choose the best UI for the credentials it knows the RP wants to use (e.g. USB only, etc).

Please close this issue if satisfied with the answer, otherwise it will likely be closed during the next working group call.

[jameshartig]

@sbweeden I appreciate the quick response and the pointer as for a better avenue in the future.

Should the spec be updated to reflect that's the intended use-case? I couldn't find any reference to credentialRecord.transports or transports that seems to indicate that it should be used in the way you described.

[sbweeden]

That's the primary use case (at least AFAIK). There is perhaps statistical or UX value in the RP knowing the transports of a user's registered credentials (you might make suggestions about registering the platform authenticator for example), so I don't think there's a compelling reason to change the specification in this regard since there is more than one possible reason for storing them.

[emlun]

Thanks for pointing this out! There is a connection, but it is a bit buried:

• Step 27 of §7.1. Registering a New Credential instructs to set credentialRecord.transports to the return value of getTransports().
• The definition of a Credential Record also includes a definition of the credential descriptor for a credential record, which instructs to set PublicKeyCredentialDescriptor.transports to the value of credentialRecord.transports.
• The definition of allowCredentials recommends to set it to a list of the credential descriptors for credential records in the user account.

So technically there is a recommendation of how to use it, but the chain of steps is certainly not obvious just by looking at the list of places where credentialRecord.transports is referenced.

It might help to somehow reference credentialRecord.transports in §7.2. Verifying an Authentication Assertion, like there is a reference in §7.1. Registering a New Credential, but the first step of §7.2 already reads:

1. Let options be a new PublicKeyCredentialRequestOptions structure configured to the Relying Party's needs for the ceremony.

and I don't really want to start weighing that down with specific callouts of individual parameters of note.

I think we could improve the description of PublicKeyCredentialDescriptor.transports and include a reference to credentialRecord.transports there, though. I think that could have the additional benefit of making the paragraph a bit shorter, too. @jameshartig does that seem like a fair solution?

[jameshartig]

The definition of allowCredentials recommends to set it to a list of the credential descriptors for credential records in the user account.

I think that was the part I was missing.

I think we could improve the description of PublicKeyCredential.transports and include a reference to credentialRecord.transports there, though. I think that could have the additional benefit of making the paragraph a bit shorter, too. @jameshartig does that seem like a fair solution?

I agree, the current paragraph talks about storing the getTransports() return and using that stored value when it could just reference the credentialRecord.transports and it would be clearer.

Thank you!