Correctness of the solid:oidcIssuer predicate

[matthieubosquet]

As discussed during the solid authentication panel https://gitter.im/solid/authentication-panel?at=5ffc6cf1fb85d46e04d5f6b0

The solid-oidc specification name seems to correctly denote the fact that the authentication described here is strongly related to OpenID Connect. See also related issue: https://github.com/solid/authentication-panel/issues/116

However, for future proofing and in light of the fact that there are different ways of authenticating, should we deprecate the solid:oidcIssuer predicate and create/recommend the use of a solid:identityProvider predicate instead?

[acoburn]

I would like to argue in favor of keeping solid:oidcIssuer

There are currently two authentication mechanisms described in the Solid Protocol Specification:

• Solid-OIDC
• WebID-TLS (support for this is not required)

If we look at these two mechanisms and consider for the sake of discussion that there is a Solid-SAML mechanism as well (there is, at present, no such SAML-based authN proposal), the question becomes: how would solid:identityProvider improve upon solid:oidcIssuer.

For WebID-TLS, the solid:oidcIssuer property (or its generic replacement) is not used, so the renaming would provide no benefit. If there were a different (non-OIDC) authN mechanism such as SAML, would the solid:oidcIssuer/solid:identityProvider be used? Very likely not; SAML follows a very different protocol.

I am not trying to create a strawman with the SAML example, but I don't see how an arbitrary alternative authN protocol will necessarily even use this property. It seems here we would be designing for something that doesn't exist.

One can also view this from a different angle. Given a set of objects for the solid:oidcIssuer predicate, we know that these are OIDC issuers and that OIDC discovery can be performed. If we have a mix of SAML entityID values and OIDC issuers mixed together in the same property, a client cannot very well understand the protocols that each identifier refers to.

In brief, I don't see any benefit in renaming the property. If there is some alternative AuthN protocol in the future that would make use of the same property, then we can revisit this, but I don't see any advantages to generalizing that property at present.

[matthieubosquet]

@acoburn I reckon enough time has passed without further comments and your answer seems to me like the correct answer to my question.

Can we close this issue?

[csarven]

When needed, oidcIssuer can become a subPropertyOf identityProvider.