#623: Cryptographically secure random UUIDs
Discussions
2021-04-19
Sangwhan: I like it. Left comments.
Ken: I'm fine with it.
Sangwhan: new API, new capability, delta to crypto. Something people have been doing crappily, getting good random data using web APIs is not straightforward. This makes it easier.
Ken: that's great.
Sangwhan: perfectly fine, many valid use cases. They have a way to evolve the API moving forward as needed, eg. change algorithm or change entropy.
Dan: what does the multi engine support look like? This will go in the web crypto WG which is closed.. so where after WICG? [leaving comment]. Important to go through W3C process for IPR.
Sangwhan: they asked if this should be in secure contexts only or allowed in insecure contexts? if you only allow it in secure contexts frameworks will use an insecure polyfill. We have a policy for new features in secure contexts only. But I think it's okay in insecure contexts.
Ken: I agree. We want people to use it.
Dan: [triaged]
OpenedApr 9, 2021
Ya ya yawm TAG!
I'm requesting a TAG review of uuid.
We propose adding the randomUUID() method to the crypto interface. This method provides an API for generating RFC 4122 identifiers. Initially, the only version of UUID supported will be the version 4 "Algorithm for Creating a UUID from Truly Random or Pseudo-Random Numbers".
Further details:
You should also know that...
This specification was originally worked on in TC39, but it was determined that the need for a CSRNG made WICG a more appropriate venue, given that WebCryptography is part of the web platform.
We'd prefer the TAG provide feedback as (please delete all but the desired option):
🐛 open issues in our GitHub repo for each point of feedback
CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING
Please preview the issue and check that the links work before submitting.
In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document. We would prefer fully public documents though, since we work in the open.
¹ We require an explainer to give the relevant context for the spec review, even if the spec has some background information. For background, see our explanation of how to write a good explainer. We recommend the explainer to be in Markdown.
² A Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.