[SECURE-CONTEXTS] should be a normative rather than informative reference

[dbaron]

The specification currently says:

The URL must be a potentially trustworthy URL as defined in the [SECURE-CONTEXTS] specification.

but then includes [SECURE-CONTEXTS] in the informative references section. The use of must in the above sentence (but see #28) makes me think that this should instead be a normative reference.

[dbaron]

(I got here from w3ctag/spec-reviews#152.)

[marcoscaceres]

I don't think we actually want this link at all. It's used for "Potentially Trustworthy URLs", which leads to:

If origin’s scheme is either "https" or "wss", return "Potentially Trustworthy".

And I don't think we want people using "wss://" URLs for identifiers. We might as well just do a scheme is "https" check instead.

[ianbjacobs]

Please bring this question back to the WG as it made a conscious decision that "always requiring HTTPS" might be overconstraining.

[marcoscaceres]

The spec already required HTTPS (or wss:). Again, quoting:

origin’s scheme is either "https" or "wss", return "Potentially Trustworthy".

The change doesn't change what was already specified.

Are you saying that someone in the WG wanted to use web socket URLs? That wouldn't make sense.

[ianbjacobs]

See this issue: https://github.com/w3c/webpayments-method-identifiers/issues/17

And discussion here: http://www.w3.org/2017/02/23-wpwg-minutes.html

The goal was not to overconstrain the syntax. The text you found was our attempt to do that.

Ian

[marcoscaceres]

Well, now that we are actually implementing, we need this.

It blocks Payment Request CR: https://github.com/w3c/browser-payment-api/issues/464#issuecomment-290248922

I don't see why it would be helpful to have rando URLs schemes, apart from being a "nice to have".

[marcoscaceres]

Ok, rereading the [SECURE-CONTEXTS], I'll reintegrate potentially trusted into the validation algo.