fix #658: add user cancelled operation Note #760
Conversation
|
This might be slightly unrelated to this particular PR, but should these steps also make the client stop accepting new authenticators (but not terminate the timer) in step 19/17? What I mean is, say an operation is initiated with two authenticators connected. The user cancels the operation on one of them, and the client then cancels the operation on the other authenticator as well. Say the user then plugs in a third authenticator, perhaps for a completely unrelated purpose. As currently specified (likely a relic from before hot plugging), the client would initiate the operation anew with this authenticator, which might surprise the user since they just canceled it. It could in some cases lead to the user inadvertently accepting the Webauthn operation instead of the unrelated task they plugged in the authenticator for. What do you think? |
|
wrt #760 (comment), sounds like a plausible situtaion, WDYT @jcjones @akshayku @leshi ? |
|
The situation does sound plausible, and I agree with @emlun that this could be surprising to the user. Since the intent of the spec seems to be that canceling an operation on one authenticator cancels the entire operation across all authenticators, is there a reason we can't just terminate the timer? |
Yes, there is: See getAssertion step 19 and §14 Privacy Considerations 2. Authentication Ceremonies. |
|
Right-o, thanks for reminding me. In that case, denying new authenticators seems like a reasonable solution. |
index.bs
Outdated
| @@ -908,6 +908,9 @@ When this method is invoked, the user agent MUST execute the following algorithm | |||
| 1. [=set/For each=] remaining |authenticator| in |issuedRequests| invoke the [=authenticatorCancel=] operation on | |||
| |authenticator| and [=set/remove=] it from |issuedRequests|. | |||
|
|
|||
| Note: An [=authenticator=] may return some indication of "the user cancelled the entire operation". | |||
| Conveyance of such an indication is client platform-specific. | |||
There was a problem hiding this comment.
I think you mean transport-specific - not platform-specific.
There was a problem hiding this comment.
Hrmm; I think Jeff means it's up to the user agent?
There was a problem hiding this comment.
whether such a "user cancelled entire operation" indication is conveyed successfully to the RP client-side JS, is specific, as I understand it, to the entire userAgent+OSplatform+transport+authenticator stack. That's what "client platform-specific" is attempting to convey.
fyi/fwiw, "client platform" (and synonyms thereof) are among our currently undefined terms. So making this stuff more clear may ultimately involve getting around to defining at least that term, seems to me.
index.bs
Outdated
| @@ -1260,6 +1263,9 @@ When this method is invoked, the user agent MUST execute the following algorithm | |||
| 1. [=set/For each=] remaining |authenticator| in |issuedRequests| invoke the [=authenticatorCancel=] operation | |||
| on |authenticator| and [=set/remove=] it from |issuedRequests|. | |||
|
|
|||
| Note: An [=authenticator=] may return some indication of "the user cancelled the entire operation". | |||
| Conveyance of such an indication is client platform-specific. | |||
There was a problem hiding this comment.
Yeah... maybe it could just be "It is unspecified how a user agent should convey this state to the user" ?
There was a problem hiding this comment.
yeah, how this state is annunciated is another aspect of this.
|
@selfissued @jcjones -- pls re-review, thx for the wording suggesting @jcjones. |
|
@selfissued Please re-review the changes |
fix #658
Preview | Diff