4 ms·

You're wrong. UUIDs don't provide any guarantees about the target of the reference. ie. Given a UUID, and a service endpoint which returns some data for a give

You're wrong. UUIDs don't provide any guarantees about the target of the reference. ie. Given a UUID, and a service endpoint which returns some data for a given UUID, the client has no way of ensuring that the data returned from the service is in fact what they asked for. A similar service operating on hash values would have the property that clients can run the same hash algorithm locally to ensure that the server isn't lying to them.

peterwwillis 14y ago
How is that different from UUID version 3 and 5, which both use hash values? https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_5_.28SHA-1_hash.29 https://en.wikipedia.org/wiki/Universally_unique_identifier#...
- snprbob86 14y ago
  My apologies. You're correct: I mistakenly equated UUID with UUID v4. That said, the difference with this new proposal appear to include at least the following: 1) Support for untruncated hashes 2) More secure hash algorithms 3) Extensibility to new hash algorithms 4) URI compatibility
  - gojomo 14y ago
    Also by my reading the UUID conventions are hashes of other names to make them fit the UUID format... not hashes of specific content.
    - peterwwillis 14y ago
      Names of a namespace, yes, but standards were meant to be broken. It doesn't really matter what you based the hash on, it's up to the application(s), much like the type of UUID you choose. The reason I like UUID better is (once you pick a version) it's simple. It already looks pretty readable and it's a well known widely-used standard. It would have been nice if the authors of this RFC had just expanded on UUID. People are also way too URI-obsessed; when are you going to pass this hashed URI to an application? IMHO an object reference should be just that and not involve application interfaces. In terms of the hashing algorithms, (IIRC) unless you're using HMAC you're opening yourself to an (eventual) brute force and key reuse issue, or at the very least the potential for an implementer to ignore the need for a random salt and get either easy collisions or predictable table insertion. I would feel pretty nervous if the hashing algorithm was my SPF.
      - gojomo 14y ago
        But unless you rigorously enforce the hash=name convention, you can't get its benefits. (Benefits like stability and implicit verification.) And shoehorning the hash into the constrained UUID format hides/confuses the conventions you're committing to. If you name is a hash, and really needs to be a hash, that should be evident, not squeezed into the bitfields of a 'UUID'.

peterwwillis 14y ago

How is that different from UUID version 3 and 5, which both use hash values? https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_5_.28SHA-1_hash.29 https://en.wikipedia.org/wiki/Universally_unique_identifier#...

snprbob86 14y ago
My apologies. You're correct: I mistakenly equated UUID with UUID v4. That said, the difference with this new proposal appear to include at least the following: 1) Support for untruncated hashes 2) More secure hash algorithms 3) Extensibility to new hash algorithms 4) URI compatibility
- gojomo 14y ago
  Also by my reading the UUID conventions are hashes of other names to make them fit the UUID format... not hashes of specific content.
  - peterwwillis 14y ago
    Names of a namespace, yes, but standards were meant to be broken. It doesn't really matter what you based the hash on, it's up to the application(s), much like the type of UUID you choose. The reason I like UUID better is (once you pick a version) it's simple. It already looks pretty readable and it's a well known widely-used standard. It would have been nice if the authors of this RFC had just expanded on UUID. People are also way too URI-obsessed; when are you going to pass this hashed URI to an application? IMHO an object reference should be just that and not involve application interfaces. In terms of the hashing algorithms, (IIRC) unless you're using HMAC you're opening yourself to an (eventual) brute force and key reuse issue, or at the very least the potential for an implementer to ignore the need for a random salt and get either easy collisions or predictable table insertion. I would feel pretty nervous if the hashing algorithm was my SPF.
    - gojomo 14y ago
      But unless you rigorously enforce the hash=name convention, you can't get its benefits. (Benefits like stability and implicit verification.) And shoehorning the hash into the constrained UUID format hides/confuses the conventions you're committing to. If you name is a hash, and really needs to be a hash, that should be evident, not squeezed into the bitfields of a 'UUID'.