Question on https access

[ghobona]

This question came up as a result of the 2021-05 OGC API code sprint.

Is it possible to access the OGC NA with "https"? From an https application it is becoming almost impossible to access http content.

[rob-metalinkage]

yes...

https://www.opengis.net/def/schema/hy_features/hyf/HY_Catchment

could go to

https://defs.opengis.net/vocprez/object?uri=https://www.opengis.net/def/schema/hy_features/hyf/HY_Catchment

or we could simply make all redirects go the https: ?

[ghobona]

We need to update the policy to specify what the relationship is between http://www.opengis.net/def and https://www.opengis.net/def

The policy only recognises http://www.opengis.net/def

[ghobona]

This has come up in a previous OGC API Virtual Code Sprint.

Several websites and browsers now prevent access to resources on http from https.

There is an increasing need to update the OGC-NA policies to allow registration of concepts under https://www.opengis.net/def.

So the proposal is:

1. To update the OGC-NA policies such that after a nominal date (e.g. 30 June 2022) all future item registrations would be under https://www.opengis.net/def instead of http://www.opengis.net/def.
2. Existing registered items under http://www.opengis.net/def would not be modified.
3. Any concepts currently registered under http://www.opengis.net/def, would need to be re-registered as new concepts under https://www.opengis.net/def, and
4. A skos:exactMatch statement would be declared to indicate a high degree of confidence that a concept in https://www.opengis.net/def can be used interchangeably with another in http://www.opengis.net/def.

[ghobona]

The proposed approach described above was discussed during the 2022-02-22 OGC Naming Authority meeting. There were no objections to the proposed approach.

[jerstlouis]

Resolving URIs when using https is a major usability issue that would really help if it were fixed:

https://www.opengis.net/def/rel

Gives an input/output error

whereas

http://www.opengis.net/def/rel

works fine.

This is really cumbersome/confusing when trying to lookup OGC link relations. (in comparison, /tms works fine with both)

[ghobona]

The policy was updated to allow for use of sameAs. This was a precursor to configuring the system to handle http and https protocoled concepts as one and the same.

So focusing on a single register to trial the approach, here is a representation of the items registered in the GeoTIFF Tag Register.

The concept http://www.opengis.net/def/geotiff-tag/ogc/1.1/33922 has an alias https://www.opengis.net/def/geotiff-tag/ogc/1.1/33922

Note that the alias concept is intentionally placed in a separate register. This is to avoid doubling the number of concepts in the original register (in this case the GeoTIFF Tag Register).

We will also need to create aliases for the concept schemes and collections.

[ghobona]

Sorry, I've had to remove the alias register briefly. I'll re-publish it in the next few hours.

[ghobona]

Ok, the alias register is back online. Below is a screenshot that explains how the information is presented.

[ghobona]

Most likely we will need separate alias registers, one for each Concept Scheme. This would avoid having a page with 200,000 records listed. It would also make it easier to manage the concepts that are in a Concept Scheme.

[avillar]

@ghobona, @rob-metalinkage, what if we 1) added a general entailment rule that created http<->https owl:sameAs, and 2) slightly modified VocPrez SPARQL queries to retrieve both the HTTP and HTTPS versions of a resource no matter which one was initially requested?

[ghobona]

@avillar If both 1 and 2 can be implemented, then that would be the ideal solution.

[avillar]

(1) can be very easily done in one of the vocprez-specific SHACL entailments. For already loaded resources, a simple SPARQL UPDATE would suffice.

(2) is just a matter of changing SPARQL { <REQ_URI> ?p ?o } patterns into { ?s ?p ?o VALUES ?s { <REQ_URI_HTTP> <REQ_URI_HTTPS> } }. This is doable the current VocPrez version (there are < 30 SPARQL queries total); we'd need to check with @nicholascar and his team on whether they think this is feasible for the new Prez version (or if they even consider it a good idea).

Once this is done, it would not matter whether the user requested the HTTP or HTTPS version, or even if we redirected them to the HTTPS automatically.

The only downside is that the embedded landing pages that Rob set up may break when using HTTPS (since many of them link to HTTP content, and HTTP iframes cannot be used inside HTTPS...).

What do you think, @rob-metalinkage?

[jerstlouis]

The only downside is that the embedded landing pages that Rob set up may break when using HTTPS (since many of them link to HTTP content, and HTTP iframes cannot be used inside HTTPS...).

As was recently pointed out to us, several organizations have policies completely preventing access to http content. For that reason and the above, ideally all of the embedded content should be available through https as well (e.g., by proxying to https that local server that provides the content through http).

[ghobona]

@nicholascar Any response to Item 2 at https://github.com/opengeospatial/NamingAuthority/issues/108#issuecomment-1568101076 ?

[ghobona]

@avillar VocPrez does not appear to support the functionality that you outlined at Comment 1568101076.

Let's proceed with the Alias approach (described at Comment 1564351314), since we know that the Alias approach works.

[ghobona]

https aliases have now been created for all http URIs.