@jcjones and I have been discussing this. It seems clear that since the overall tasks of credential "creation" and "getting" begin in the credman spec and go async there (e.g., in this alg, in the "create" case), that the issue of creating copies of any buffersources within CredentialCreationOptions or CredentialRequestOptions lie with the credman spec.

Also, since CredentialCreationOptions and CredentialRequestOptions are dictionaries, it is not clear whether we can (or should) use e.g. structuredserialize to perform the copy of CredentialCreationOptions or CredentialRequestOptions or whether we ought to instead craft language such as:

"make a deep copy of |options|, such as by recursively cloning fields, except for BufferSource objects where one will need to get a copy of the bytes held by the buffer source".....

..?

cc: @mikewest @bzbarsky

After thinking about the creating-a-deep-copy-of-a-dictionary-with-any-buffersources-bytes-copied thing on my bike ride yesterday evening, it seems that if we need to explicitly specify how we recurse through a potentially complex dictionary and get copies of buffersource bytes, we can perhaps leverage the "[An IDL dictionary value V is converted to an ECMAScript Object value]

[UPDATE 8-Oct-2018]: I realized that since dictionaries are passed-by-value, it seems we do not need to make a copy of the entire options dictionary (?), rather we just need to copy any buffer sources' data, And then in the original options dictionary, update the associated value of type buffer source to point to the newly copied data, and then pass the options dictionary down into the in parallel alg section (?).

So I've updated the below alg to (hopefully) accomplish this (the original "dict deep copy" alg is preserved at end below), my nominal name for this new alg is <dfn>create a copy of any buffer sources' data</dfn>:

To <dfn>create a copy of any buffer sources' data</dfn> 
referenced by a dictionary value |V|, run this algorithm:

1. Let |dictionaries| be a list consisting of |V| and all of |V|'s 
    [=inherited dictionaries=], in order from least to most derived.

2. For each dictionary |dictionary| in |dictionaries|, in order:

    1. For each dictionary member |member| declared on 
         |dictionary|, in lexicographical order:

        1. Let |key| be the [=identifier=] of |member|.

        2. If the dictionary member named |key| is [=present=] in |V|, then:

            1. Let |value| be the value of |member| on |V|.

            2. If |value|'s type is a [=buffer source type=] then 
                [=get a copy of the bytes held by the buffer source=] and 
                set |values|'s value to be a reference to the copy of the bytes.

Then, at the beginning of the credman algorithms to which we pass CredentialCreationOptions or CredentialRequestOptions dictionaries, we can have a new step something like the following (before the alg goes "in parallel":

n. [=create a copy of any buffer sources' data=] referenced by |options|.

..and then use |options| in the "in parallel" portion of the alg.

It seems to me that the specification of the [=create a copy of any buffer sources' data=] alg ought to be in some other spec other than credman -- e.g. Infra? WebIDL?

thoughts?

UPDATE 8-Oct-2018: I'm parking the original <dfn>create a deep copy including any buffer sources</dfn> alg (I previously had written above) here in case it is ever useful

To <dfn>create a deep copy including any buffer sources</dfn> 
|dictCopy| of a dictionary value |V|, run this algorithm:

1. Let |dictCopy| be an empty dictionary of type [=dictionary type=]
    with every [=dictionary member=]
    initially considered to be [=not present=].

2. Let |dictionaries| be a list consisting of |V| and all of |V|'s 
    [=inherited dictionaries=], in order from least to most derived.

3. For each dictionary |dictionary| in |dictionaries|, in order:

    1. For each dictionary member |member| declared on 
         |dictionary|, in lexicographical order:

        1. Let |key| be the [=identifier=] of |member|.

        2. If the dictionary member named |key| is present in |V|, then:

            1. Let |value| be the value of |member| on |V|.

            2. Let |newDictMember| be a new [=dictionary member=]
                of |dictCopy| named |key|, and having the same type as |value|,

            3. If |newDictMember|'s type is:
                <dl class="switch">
                     : a [=buffer source types|buffer source type=]
                     :: [=get a copy of the bytes held by the buffer source=] and 
                        let |newDictMember|'s value be a reference to the copy of the bytes.
                     :  anything else
                     :: Let |newDictMember|'s value be |value|.
                </dl>

Having some sane way to clone dictionaries like that makes sense to me. @domenic @annevk thoughts on the proposal above and where something like that would live?

And note that how this should work for dictionaries containing references to instances of WebIDL interfaces (say Node or something) is not really that clear. One option is to have the algorithm preserve all the values in the dictionary except buffer sources, I guess, and copy those....

@bzbarsky wrote:

One option is to have the algorithm preserve all the values in the dictionary except buffer sources, I guess, and copy those....

yeah, I attempted to update the alg (apparently while you were reviewing it) to do "preserve all the values in the dictionary except buffer sources ... and copy those".

If we offered utilities around dictionaries with regards to IDL values, they should be defined in IDL I think. It's not clear something generic is possible though, we'd need several instances to figure out if there's a pattern here, though passing dictionaries to "in parallel" is something I vaguely recall having seen before.

Are you sure you want to create copies by the way? Is the person who passed these values going to reuse them for something? Otherwise it might be more efficient to transfer ownership and detach the passed in objects.

Are you sure you want to create copies by the way? Is the person who passed these values going to reuse them for something? Otherwise it might be more efficient to transfer ownership and detach the passed in objects.

I think that would be fine as well, keeping in mind that the real source issue here is the possibility of asynchronous modification to buffer sources. So detaching everything is fine, as long as we also detach any embedded buffer sources.

Assigning this to me, as per conversation in WebAuthn.

@annevk: Do you think that the "create a deep copy including any buffer sources" algorithm above ought to live in Infra? Or should we just stick it in credential management and call it done?

@mikewest noted:

as per conversation in WebAuthn

recap of conversation? It does not seem to be minuted, thx.

Do you think that the "create a deep copy including any buffer sources" algorithm above ought to live in Infra?

So you guys are thinking we ought to codify and use the "create a deep copy including any buffer sources" algorithm rather than the lighter-weight "create a copy of any buffer sources' data" one (both above in #128 (comment)) ? rationale (am curious) ? (note: I think the "create a copy of any buffer sources' data" alg does what @bzbarsky is musing about in #128 (comment)).

Also, why not modify "create a copy of any buffer sources' data" to do a "transfer" per #128 (comment) and #128 (comment) ?

I think the algorithm should be inline for now. The other consideration with transfer vs copy is size I suppose. If these are never going to be large buffers, it might not be worth trying to free the memory. On the other hand, if they never ought to be reused, you might as well do it that way for safety.

on 23-Oct-2018 webauthn tpac meeting call -- mikewest & jc think that the way to go is "copy" rather than "transfer" and we just need to figure out which of the versions of the proposed algs in #128 (comment) we ought to use.

And specifically WebAuthn's use case has small, predictable-sized buffers -- they aren't likely to be used for many-kilobyte buffers. A rogue website using megabyte buffers could cause some performance degradation, but they'd have to be able to use WebAuthn anyway (either a top-level document, of (ultimately) permitted via feature-policy).