Clarify how the given origin in the ClientDataJSON matches to the expected one

[Kieun]

Proposed Change

In the spec, there are multiple occurrence around origin matching.
For example, in section 7.1. Registering a New Credential, there is a following step.

9. Verify that the value of C.origin matches the Relying Party's origin.

Some of implementations in OSS just maintain list of acceptable origins and simply compares the given origin with the list by simply text equality.

It would be better to explain or add text about the matching logic in more detail.

[james-d-elliott]

RFC3986 normalization methods such as Section 6.2.2 Syntax-Based Normalization (specifically point 1 as I don't believe the other points apply to the origin portion of a URI), Section 6.2.3 Scheme-Based Normalization, and Section 6.2.4 Protocol-Based Normalization are probably the most appropriate normalization types to use (in order of importance).

Theoretically a simple string comparison with case normalization is probably the most appropriate minimum requirement.

[MasterKale]

Some of implementations in OSS just maintain list of acceptable origins and simply compares the given origin with the list by simply text equality.

Is the issue that strings may not be normalized by the client? I guess I'm not understanding how this process needs to be defined more robustly.

[Kieun]

@MasterKale
At least, it's meaningful to add some references to indicate the way of origin comparison.

[james-d-elliott]

I think there is also some level of user interaction with the consistency of the strings on RP side. For example the administrator may not provide a string consistent with the value the client does. The developer implementing the RP would realistically be expected to account for this in some way.

[ndpar]

Should't origin be compared the same way RP ID is compared?

[ndpar]

I agree with @Kieun, the spec is too vague about origin matching. It references web origin RFC6454, but it doesn't mandate the origin to be a web origin. This allows, for example, Android native API to send android:... origin instead.

The spec should say that both client and RP origins must be web origins, if that's the case, and the origin matching should be done the same way RP ID matching is done. If it is not the case, and the origin can be just a string, then explicitly specify matching rules for such strings, i.e. string equality, binary equality, etc. If there are some constraints for the origin values, specify them as well.

Back to my example. Is android:... a valid value for the origin? If so, how do I match it? What if I get xyz:... origin from the client, how should I match that?

If the phishing-resistance promise of WebAuthn is based on the origin (and RP ID), we should be very specific about origin matching.

[timcappalli]

Back to my example. Is android:... a valid value for the origin? If so, how do I match it? What if I get xyz:... origin from the client, how should I match that?

Yes, this is a valid origin for an app on Android.

If the phishing-resistance promise of WebAuthn is based on the origin (and RP ID), we should be very specific about origin matching.

RP's need to ensure that the origin included in clientData is an expected origin during verification.

[ndpar]

RP's need to ensure that the origin included in clientData is an expected origin during verification.

Does it mean the rule should say "RP origin list must contain the clientData origin; values are compared using string equality."? And case-sensitivity would be different for web vs other types of origins, I presume.

[Kieun]

The term matching is vague and if there is anything to check against to the expected origin, it's better to describe the way of comparison by adding some texts or references.

[Ret1ge]

يحتاج RP إلى التأكد من أن الأصل المتضمن في clientData هو أصل متوقع أثناء التحقق.

هل يعني ذلك أن القاعدة يجب أن تقول "يجب أن تحتوي قائمة أصل RP على أصل clientData ؛ تتم مقارنة القيم باستخدام مساواة السلسلة."؟ وستكون حساسية حالة الأحرف مختلفة للويب مقارنة بأنواع الأصول الأخرى ، كما أفترض.