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

> `version` is the minimum version of the Android application.

Then could I suggest calling it `min_version`?

> Can anyone elaborate on why that's better than adding `"version"` and `"sha256_cert_fingerprints"` directly into the dictionaries of `"related_applications"`?

It's an issue of how it's defined in the specs and how it interops across platforms and future versions of the Manifest spec.

Since these two fields are proprietary to Android, you can't just get them added to the Manifest spec as fields of `related_applications`, you have to specify them "somewhere else" (neither in the Manifest nor the Web Payments spec, but in some Android-specific documentation). Each platform could potentially define different fields here. The key is that a platform-specific field should not block the addition of a new field later down the track to the official spec. For example, if the Manifest spec wants to add a "version" field with a specific meaning, we don't want to have an objection "we can't add that because [PLATFORM-X] already has a field called version with its own proprietary meaning". So you have to name it in a way that won't conflict with any future features.

**On the other hand**, we could go down the route of actually specifying these as non-proprietary fields. If we did go down this route, we'd have to wriggle them around to make them not specific to Android. Here's a quick brainstorm of how we could change it to cover all platforms:
* Make `min_version` a string, and specify it as "the minimum version of the app; how the version strings are interpreted and ordered is at the discretion of the platform". It's a string because on most systems, version numbers can be arbitrarily complex, not simple ints like they are on Android. For example, Debian defines a strict, but complex, [ordering on version strings](https://www.debian.org/doc/debian-policy/ch-controlfields.html).
* Make the hash a bit more generic. Call it `fingerprints`, and spec it as a list of dicts with keys: {`format`, `value`}. `format` would be `"sha256_cert"` for Android, with space for future fingerprint types, and `value` would be the fingerprint in an Android-proprietary format.
* The idea is that both `version` and `fingerprints` (along with `id`) are meaningless in general; their meaning is imposed by the platform. But the spec tells us the general format that these fields should take.

The new version of Zach's example becomes:

```json
"related_applications": [
    {
      "platform": "play",
      "url": "https://play.google.com/store/apps/details?id=com.bobpay",
      "fingerprints": [  //new
        {"format": "sha256_cert", "value": "59:5C:88:65:FF:C4:E8:20:CF:F7:3E:C8..."}
      ],
      "version": "1",  // new
      "id": "com.example.app1"
    }, {
      "platform": "itunes",
      "url": "https://itunes.apple.com/app/example-app1/id123456789",
    }
  ]
```

Now I'm actually leaning towards specifying this in the Manifest as opposed to adding a "meta" proprietary value bag. Thoughts?

-- 
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-290297034