Does the OpenID Connect Core specification incorrectly define the OpenID Provider and Relying Party in terms of human participants?

Question

There are a few important definitions in the OpenID Connect Core specification that refer to a human participant, and at first glance it would seem that OpenID Connect only applies in cases where there is a human participant, but this is not true in practice. Are these terms incorrectly defined in terms of human participation, and should they have been defined more generally to encompass usage where there is no human participation?

Here are the definitions, with other defined terms also in bold (those definitions are listed below as well):

• End-User: Human participant
• OpenID Provider: OAuth 2.0 Authorization Server that is capable of Authenticating the End-User and providing Claims to a Relying Party about the Authentication event and the End-User
• Relying Party: OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider

Despite the existence of the above human-centric term definitions, there are many other relevant definitions in the specification that either explicitly state or imply that a human participant is unnecessary. Given these additional definitions (see below), it is clear that the use of OAuth 2/OpenID Connect in a context without human interaction is reasonable -- and in fact it is widely supported. Here are those definitions:

• Entity: Something that has a separate and distinct existence and that can be identified in a context. An End-User is one example of an Entity (implying there are other examples that are not human participants).
• ID Token: JSON Web Token (JWT) that contains Claims about the Authentication event. It MAY contain other Claims.
• Authentication: Process used to achieve sufficient confidence in the binding between the Entity and the presented Identity.
• Identity: Set of attributes related to an Entity.
• Claim: Piece of information asserted about an Entity.

The OpenID Connect Core specification uses several terms defined by the OAuth 2 specification that support the notion of interaction without human involvement:

• Resource Owner: Entity capable of granting access to a protected resource. When the Resource Owner is a person it is referred to as an End-User (implying there are other examples that are not people).
• Resource Server: Server hosting protected resources, capable of accepting and responding to protected resource requests using Access Tokens.
• Client: Application making protected resource requests on behalf of the Resource Owner and with its authorization.
• Authorization Server: Server issuing Access Tokens to the Client after successfully authenticating the Resource Owner and obtaining authorization
• Access Token: Credentials used to access protected resources; it is a string representing an authorization issued to the Client.

Given all of this, I can't help but think that the definitions of OpenID Provider and Relying Party should have referred to Entity instead of End-User. Am I correct?

Answer 1

No, the definitions are correct.

Keep in mind that a relying party does not authenticate but gets authorised through the process where the end user first authenticated and then supplied an authorisation (in the form of a token) to the relying party.

More clarification on your final comment:

• The OpenID provider does not Authenticate any Entity, it is specifically an Authorisation Server capable of Authenticating a human END USER.
• The Relying Party is an application, either running on a server or on a user's device. A human User needs to have Authenticated prior to a token being provided to the Relying party, hence the work End User in the definition.

Answer 2

OpenID Provider is a server.

Relying Party is an application.

Sure, servers and applications don't appear on their own. Humans develop applications, humans deploy and configure them, humans define security policies. But we don't consider how it was configured. We consider how it acts.