geo-location securityMethod?

[Markus Demleitner]

Dear colleagues,

I'm not quite sure where to go with this, but since it could have
something to do with our work on auth method identifiers for
SecurityMethod, I thought I should cc: gws.  Discussion, I'd suggest,
should take place on registry.

The problem popped up with ivo://nci.org.au/skymapper/tap -- that's a
properly registred TAP service, as it should be.  However, access is
limited by (I suppose) IP ranges to something like "within
Australia".

Now, for GloTS (you may remember the globally federated TAP schema),
this is a bit of a problem, because it tries to hit this service once
every 12 hours and of course gets rejected, which results in log spam
on my end.

This type of "global TAP operation" will, I predict, become more
important as more common data models like Obscore emerge, and clients
should have a way to decide whether a failure of a remote service is
to be expected (because of missing "credentials") or whether a
service just has a temporary downtime and the user should be bothered
with diagnostics.

At this point I think securityMethod might be a reasonable way to do
this -- if an interface defines a securityMethod, in GloTS I (and in
future all-VO Obscore searchers their authors) could just ignore it.

However, we don't have a securityMethod id defined for "access
control by IP address" (or perhaps something a little more generic.

Well, could we?

An alternative I can see might be to say that clients are advised to
take 403 forbidden as a non-failure.  Which might be easier overall,
but somehow I think this rule will hide genuine errors.

        -- Markus