search

tc39 / proposal-uuid

UUID proposal for ECMAScript (Stage 1)
463 stars 7 forks source link

contributing to proposal #1

Closed bcoe closed 5 years ago

bcoe commented 5 years ago

👋 @broofa, @ctavan, @littledan, @defunctzombie

You should have all gotten an invite to this repo, the way things work are as follows:

  1. we flesh out the proposal.
  2. the proposal is presented by a champion at TC39.
  3. if accepted, this repo is moved into the TC39 org.

Folks should feel free to pitch in and start fleshing out the various sections; I've based the template on https://github.com/tc39/proposal-top-level-await, based on @littledan's advice.

Areas that need the most work

@littledan @broofa, we need to make a case in the document for which UUID formats we would like to implement at the outset.

@littledan, I wasn't quite sure about how to describe the algorithm in ecmarkup; and wasn't sure how deep we should go -- would love some direction. From the tiny bit of research I did, I think we can build the v4 algorithm using crypto.getRandomValues, logical or, and bit-shift operators; so shouldn't be hard to describe the algorithm in the abstract; sounded like the other algorithms are more complex @broofa?

ctavan commented 5 years ago

I would judge the order of complexity of the algorithms like this:

(least complex) v4 << v3/5 < v1 (most complex)

with v4 being the by far simplest algorithm.

So as you've already suggested in the call I guess it makes sense to flesh out this proposal for v4 first and then use the structure that emerges as a template for v1 and v3/5 (should we decide to include these types of UUIDs at all).

I'm happy to help drafting as soon as we get to discussing v1 but will leave v4 to you (@broofa / @littledan) for now 😉.

littledan commented 5 years ago

I think we should liberally reference the algorithm's definition in the RFC, rather than re-describing it here. I would hold off on spec text and focus on the API design and README first, polyfill with tests second, and spec text third.

littledan commented 5 years ago

As for the source of randomness, I don't think referencing anything like WebCrypto would be helpful. I am debating between omitting any characterization of the randomness and vaguely saying that it should be good.

broofa commented 5 years ago

I concur as far as the order of support for versions. The caveat there being that whatever API we start with must allow for other versions to be easily added. (node-mime started out with v4 as the default export, which was problematic as support for other versions were later added.)

Regarding how to specify the implementation and (within that) the source for random numbers, a "reference implementation" of some sort seems like an obvious step. I'm not sure how/if that falls within the purview of the formal specification, is simply referenced by the spec, or is mentioned alongside the spec in whatever related docs emerge.

That said, the issue of PRNG quality is a legit security issue, so I'd suggest that the spec require an error be thrown if a high-quality source of randomness is not available.

littledan commented 5 years ago

@broofa We've avoided reference implementations as part of specifications in the past. Do you have a recommendation for how we should characterize a high-quality source of randomness in words? I'd suggest just requiring it (if we can figure out how to word it), rather than throwing an error.

bcoe commented 5 years ago

@broofa @littledan I think (and Dan would know better than me) It's probably sufficient for browser vendors to have the stanza:

"generated using a secure source of randomness"

somewhere in the spec?

broofa commented 5 years ago

I'd opt for "generated using a cryptographically secure source of randomness". (That's the term of art I've seen most often, and has a bit more precise meaning.)

bcoe commented 5 years ago

Have landed some of the initial edits, let's gravitate towards more targeted issues.