Webauthn: What does "the extension was acted upon" mean for the AppID extension?

[emlun]

§10.1. FIDO AppID Extension (appid) reads:

Client extension output
Returns the value true to indicate to the RP that the extension was acted upon.

What exactly does "the extension was acted upon" mean? I see at least two ways to interpret this:

1. The output is true if and only if the extension was processed - regardless of which of the RP ID and AppID was ultimately used.
2. The output is true if and only if the extension was processed AND the AppID was used instead of the RP ID.

I think a strict technical reading would conclude (1), but I think that most readers would expect (2). For example, the suggestion

add clarification to step 11 indicating that appid in the client extension outputs may need to be checked first to ensure the correct rpIdHash is compared

in #980 seems to be based on interpretation (2).

[emlun]

@akshayku @kpaulh What are implementations currently doing? (I don't know who from Mozilla to ask...)

[agl]

(I continue to believe that appid should not have a return value.)

Chrome's behaviour is that the appid return value exactly mirrors the input value. (I.e. case (1).) The motivation here is that option (2) is moot: the RP knows whether the credential was registered with U2F and so, if such a credential worked via webauthn, then clearly the extension was respected.

Also, Chrome behaviour is that appid is _always_ returned (even if appid wasn't a specified extension) because the return value element isn't optional. We're probably going to change that to just unilaterally make it optional in Chrome (bug).

[emlun]

Ok, thanks @agl!

Also, Chrome behaviour is that appid is _always_ returned (even if appid wasn't a specified extension) because the return value element isn't optional.

Do you mean that this is because the appid member of the partial dictionary AuthenticationExtensionsClientInputs is not optional? That seems to me like it might be a bug in the spec. I made the same interpretation as @kpaulh: that the dictionary extension shouldn't be applied unless the extension is requested.

[agl]

Do you mean that this is because the appid member of the partial dictionary AuthenticationExtensionsClientInputs is not optional?

Yep.

I made the same interpretation as @kpaulh: that the dictionary extension shouldn't be applied unless the extension is requested.

I agree that makes the most sense in this context, although I find scant support for the idea that partial dictionaries can be dynamically composed from reading WebIDL. But what happened here is that I used the appid definition from the spec verbatim in our WebIDL input and that resulted in the described behaviour which I didn't think too much about at the time.

[emlun]

[...] I find scant support for the idea that partial dictionaries can be dynamically composed [...]

Ah, I see. I don't know what we could do to address that, though...

Returning to the topic of the issue, though: @selfissued do you have any comment on what "the extension was acted upon" means for the appid extension?

[equalsJeffH]

just to note, from webidl wrt dictionaries:

On a given dictionary value, the presence of each dictionary member is optional, unless that member is specified as required. When specified in the dictionary value, a dictionary member is said to be present, otherwise it is not present.

Sounds to me that JS objects defined by webidl dictionaries can be constructed dynamically. Or am I misunderstanding what you @agl mean wrt "dynamically composed" ?

[akshayku]

Coming back to the original question, my interpretation and implementation of "true" is case(2). Otherwise, I don't see any value for returning this boolean. My interpretation was that when RP sees this value, it can see whether RPID hash was used in authenticatorData or AppId hash.

Saying RP will always know whether credential was created with U2F or not will not be correct in the future where U2F credentials will be created using webauthn APIs which will use RPID instead of AppId.

[emlun]

Saying RP will always know whether credential was created with U2F or not will not be correct in the future where U2F credentials will be created using webauthn APIs which will use RPID instead of AppId.

It will remain correct in the sense that the AppID needs to be used if and only if the credential was created via the U2F _API_. The RP does know (or at least, it's within the RP's power to know) if a given credential was created with the U2F API or the WebAuthn API.

And even if the RP doesn't know this, that doesn't matter much in practice - the RP does definitely know whether it requested the appid extension, so if it did and the verification against RP ID fails, it can simply try verifying against that AppID and see if that works instead.

So as far as I'm concerned it doesn't matter much which of the two options we choose, but I think we need to precisize this since the behaviour is evidently underspecified.

[akshayku]

This boolean always returning true whether appid was used or RPID was used makes no sense to me.

This behaviour makes this boolean meaningless and this behavior is not intuitive and less efficient. Then RP will need to have a retry verification logic and try to deduce what happened which results in less clean approach and results in more error prone code, IMO.

[selfissued]

It seems like we should specify that true is returned when (2) is the case:

1. The output is true if and only if the extension was processed AND the AppID was used instead of the RP ID.

That seems both more intuitive and more useful than (1).