Clearly define the way how RP handles the extensions

[Kieun]

WebAuthn defines the list of the extensions. Some of extensions are client extensions and some are authenticator extensions. In the viewpoint of RP, RP may set list of extensions during create or get ceremony and expect to get the extension outputs by calling getClientExtensionResults() or decode extension within the authData. In case of client only extensions, RP surely needs to get client extension result by calling the defined function. But for the authenticator extensions, it is not clear which parts should be looked into by RP side. I added below to clarify the issue.

In section 5.7, the documents say authenticator extension outputs are conveyed in AuthData.

Note: Authenticator extension outputs are conveyed as a part of Authenticator data (see Table 1).

So, RP assumes that any authenticator extension which is respected by client and authenticator is the part of AuthData.

But, some authenticator extensions are defined that the output can be a part of AuthData. UVI, UVM

If the RP is trying to use authenticator extensions, which part of response RP needs to look at it and how RP process them properly?

1. Check client extension output only
2. Check client extension output first, then check the extension within AuthData
3. Check extension in AuthData

As per my understanding, anyway RP needs to decode (parse) AuthData for create/get response so that RP can investigate the extension in AuthData. And, some authenticator extension output should be signed to provide integrity (e.g., txAuthSimple, txAuthGeneric). So, for RP, I think that 3 is enough for check extension in AuthData.

As a result, we need to clarify weather the authenticator extension output is transferred as a part of Authdata or not (Mandatory or optional). And, it's better to have some clear guideline for RP.

BTW, when I've tested with Chrome for UVM, Chrome only included authenticator extension output as a client extension output. The extension output is not conveyed in AuthData.

[agl]

From call of 2019-07-17: we agree that this isn't terribly clear. Maybe we should do something about that. PRs welcome? For now, since nobody jumped up to write this, it has been tagged for Level 3.

[Kieun]

I added more clear description of the issue.

[Kieun]

@agl @emlun before writing the PR, I would like to listen your thoughts regarding this. For authenticator extensions, the supported output should be conveyed in AuthData. right?

[emlun]

Sorry for the delay. Yes, for the extensions where the client extension outputs forwards the authenticator extension outputs, I'd say the authenticator extension outputs in the signed AuthData should be preferred over the unsigned client extension outputs. For extensions where the client extension output and authenticator extension output are different (appid, authnSel, biometricPerfBounds, credProps), the RP should inspect both (none of those extensions have authenticator extension output, but future extensions might).

[Kieun]

@emlun I'm thinking that appId, authnSel, biometricPrefBouns and credProps are the type of client extension. They don't need any other communication with authenticators. So, at least for the authenticator extension, the authenticator extension inputs should exist and be delivered to the authenticator. Also, the authenticator extension output can be conveyed within the AuthData. My understanding is that RP needs to check the list of client extension output for client only extension and for authenticator extension, RP needs to investigate the extensions within the AuthData.

[madwizard-thomas]

Is it possible to have authentication extension output but not have client extension output for a single extension?

[Kieun]

@madwizard-thomas If the extension is a kind of authenticator extension, it just implies that the extension is for authenticators. If the client and authenticator respect (support) the request, it should return extension output (authenticator, client).