Use URI instead of URL for related origins

[opotonniee]

I don't know if this has already been discussed (I suspect so!), but I couldn't find it in this project's issues:

The "Validating Related Origins" section only allows to list URL values in the "origins" field. This is fine for related web applications.
Could we extend this feature to also list related mobile applications, by allowing listing mobile specific URIs such as:

• android:apk-key-hash:<sha1_hash-of-apk-signing-cert>
• ios:<application-identifier-prefix>.<bundle-identifier>

This would ultimately allow to replace the current proprietary well-known files (assetlinks.json for Android, apple-app-site-association for iOS) by a single and standardized file.

Corresponding changes to the specification would be:

• valid related origin values are URI instead of URL
• if URI scheme is https then the existing description still stands
• if URI is another scheme and the client does not recognize it, then it must silently ignore the entry
• if the client recognizes the URI scheme, it should validate that the application issuing the WebAuthn request is matching the URI
• optionally the spec could define URIs for android and ios apps (see above)

[timcappalli]

This was a conscious design choice for this feature (only web applications), as that is what the WebAuthn specification defines. Web Authentication is a Web Platform API and does not actively define App Platform capabilities or behaviors.

Each app platform implements its own web origin to app identity binding, they've been in production for many years, and most of the time it used for more than just FIDO2/WebAuthn.

[opotonniee]

Noted, although I think it would provide a more consistent solution across clients. New client types would not have to define their own binding. And all related applications would be listed in a single place, whatever their type (web, Android, iOS, or others).

Thanks for the quick feedback.