Re: [w3c/webpayments] Finer points of integration with Web App Manifest (#225)

[Now bikeshedding] Re the discussion about the name "format" and the syntax of the "value" field: I chose "format" (as opposed to "bits", "algorithm" or equivalent) precisely because it captures all of these aspects:

- Which algorithm is used.
- How many bits it takes.
- How it is represented (e.g., hexadecimal, base64, colon-separated octets, decoded as Latin-1 and escaped, etc).

This allows each platform to define a set of "formats" which they define all of the above aspects. For example, a platform could specify (strawman: don't do this) a format "checksum" which is just an integer sum of all the bytes of the package, expressed as a decimal integer (as a string). That doesn't fit cleanly into a scheme that says "you must express your fingerprint as a series of hexadecimal-encoded octets".

> The *format* is 256 bits.

I disagree that the word "format" implies just the number of bits.

> Would `"algorithm"` or `"digestAlgorithm"` be better than `"format"`?
...
> It's also unclear that colon-delimited hex is what is to be expected, no?

This is going down a different route which is being more descriptive in the spec (which I am OK with also). In this route, we would call it `"algorithm"` and it would be `"sha256"` (no "cert"). The syntax would be specified as a run of hexadecimal-encoded octets (probably with no colons). The format would be the same across all platforms, but different platforms could define their own hashing algorithms, and also define what exactly is the object that's being hashed (e.g., on Android it's the APK).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/225#issuecomment-291321407