Please ensure that all ArrayBuffer creations are done explicitly, in the correct global

[bzbarsky]

Right now it looks like the authenticator is expected to create ArrayBuffer when creating attestations, but it simply doesn't have the information to do so in the right global, as far as I can tell...

[equalsJeffH]

given merge of PR #371 -- is this issue now addressed?

[bzbarsky]

I don't see that it is. We're talking about the last step of the "when this operation is invoked" steps of https://w3c.github.io/webauthn/#op-make-cred here, I think.

[equalsJeffH]

We're talking about the last step of the "when this operation is invoked" steps of https://w3c.github.io/webauthn/#op-make-cred here, I think.

the #op-make-cred section is part of an abstract functional model as described in the intro portion of #authenticator-model, and it does not define the mechanics of how the authenticator ops return values to the user agent. The 3d paragraph says:

For authenticators, this model defines the logical operations that they must support, and the data formats that they expose to the client and the Relying Party. However, it does not define the details of how authenticators communicate with the client platform...

However, we attempt to address that from the user agent perspective in e.g. Step 17 branch "If any authenticator indicates success" of #makeCredential by indicating that the new ScopedCredentialInfo object (into which the value returned by #op-make-cred is copied) is allocated from |global|, which itself is this WebAuthentication object’s environment settings object’s global object. And similarly for #getAssertion in its Step 13.

Does this make sense / help ?

[bzbarsky]

Ah, I see.

What you probably want is "let value be a new ScopedCredentialInfo object associated with global" and "a new ArrayBuffer created using global's %ArrayBuffer%" (with this last linking to https://tc39.github.io/ecma262/#sec-arraybuffer-constructor).

[equalsJeffH]

alrightie, thx for feedback, pls review fixes in PR #377

[jyasskin]

@bzbarsky I'd like to fix this centrally in whatwg/webidl#135, rather than scattering one-off fixes across all web specs.

[bzbarsky]

@bzbarsky I'd like to fix this centrally in whatwg/webidl#135

It's not clear to me that it would help here, given the async behavior. Maybe it would....

[equalsJeffH]

@bzbarsky I'd like to fix this centrally in whatwg/webidl#135

It's not clear to me that it would help here, given the async behavior. Maybe it would....

How about we go ahead with PR #377 for now, and if some one-size-fits-all baked solution materializes in heycam/webidl, we can migrate to it then?

[equalsJeffH]

I'd proposed:

How about we go ahead with PR #377 for now, and if some one-size-fits-all baked solution materializes in heycam/webidl, we can migrate to it then?

...and on the webauthn call this morning @jyasskin said he's fine with that proposal.