Do we care about authentication in the spec?

[CasperWA]

If a database wants to implement authentication, should this be defined in the specification or is the provider free to do what they wish?

[merkys]

I guess the spec should not care about the authentication, as providers' mechanisms of authentication will be different (SSL certificates, tokens or else) and separate. Unless, of course, a subset of providers agree on using a SSO or like.

[CasperWA]

The latter part raised here, is exactly a use case of mine. For the MarketPlace project we intend to implement OPTIMADE as a supported way of connecting a database to the platform, however, we use OAuth2 SSO services to get a token that is passed around. This is used to verify that a specific user has the access rights to given resources, e.g., databases. I was merely asking whether the Materials-Consortia wanted to outline some requirement or guidelines for implementing various authentication methods in OPTIMADE databases, or if this is completely open.

Maybe completely open is the best choice for an open source, open science, open licensed specification?

[rartino]

As I recall, authentication was discussed at one of the first meetings, and it was said that providers may do what they want; beyond that provider-specific parameters to the URL need to be allowed to support certain authentication schemes.

What problem/use case would we address with further standardizing authentication?

[CasperWA]

What problem/use case would we address with further standardizing authentication?

I can't come up with one.

And I am happy about this answer. It was merely a documented answer I was looking for :)

Will close now. For others: If you feel you have a specific use case, which would benefit from standardized authentication in the OPTIMADE specification, please reopen the issue or create a new one outlining your use case.

[ml-evs]

I think it might be worth reopening this; there are a few databases that require API keys to access what are otherwise "public" APIs (see e.g. the MP's non-OPTIMADE API). I would suggest we add a standard place within the index meta-db for databases to report if any authentication is required, so that clients can provide more useful errors, e.g. "This database requires an API key that can be obtained from: ".

In the simplest case this could just be a free-text field, or we could define an enum for various cases e.g. requires_api_key, restricted or public (like aggregate).

Relatedly, we have just added a method for providing arbitrary HTTP headers when validating implementations https://github.com/Materials-Consortia/optimade-python-tools/pull/806.

[merkys]

In the simplest case this could just be a free-text field, or we could define an enum for various cases e.g. requires_api_key, restricted or public (like aggregate).

To me the classification seems to be even simpler:

• Open-access. Anyone can access the data.
• Restricted. Some sort of authentication is required: either API key, HTTP header-based authentication, SSL etc. New users of these services should in most general sense be directed to human-readable description on how to acquire credentials and how to supply them.

To me it boils down to a single field authentication with value null (default) for open-access providers, and JSON API links object directing to the description on how to obtain credentials and use them.