authenticatorCancel seems like it can cancel too much

[bzbarsky]

Say a client has makeCredential called. It kicks off a bunch of authenticatorMakeCredential operations and waits.

Now before those have finished there is a getAssertion call with a very short timeout. The client kicks off some authenticatorGetAssertion operations and waits. The timeout is reached. The client is expected to do an authenticatorCancel on all the authenticators, which will cancel those still-pending authenticatorMakeCredential calls. That seems pretty odd to me.

[selfissued]

Is there a specific change or clarification to the semantics of these operations being proposed?

[bzbarsky]

Well, the specific change that would make sense to me is that a getAssertion call that times out should not cancel anything to do with completely unrelated makeCredential calls, no?

[selfissued]

@bzbarsky 's suggestion sounds reasonable to me.

[equalsJeffH]

@mikewest notes that this is related to #380

[bzbarsky]

Similarly, should a getAssertion with a short timeout be able to cancel stuff from a different getAssertion call?

Basically, what's the actual model here?

[kpaulh]

I'm not sure this is a problem, given the way the spec is written. The spec specifies that authenticatorCancel should only apply to operations within a specific authenticator session. The timeout algorithm also further scopes cancellation to authenticators that are present in the issuedRequests list, which should only be authenticators processing the current getAssertion or makeCredential call. That sounds like it already specifies the behavior that @bzbarsky suggested?

[bzbarsky]

I'm not sure what "current getAssertion call" means. These are async operations; multiple getAssertion calls can be in flight at once, right?