Consideration for cases where RP is not directly addressable by OP (e.g., internet accessible OP, private network RP)

[simon-canning-octopus]

remote procedure call from the OP to the RP that enables OPs to manage the Account lifecycle, building upon the existing OP / RP relationship to cover the full spectrum of Account management requirements

OP commands require the RP to expose an endpoint that is accessible to the OP. I'm unaware of other cases where this constraint exists in other OpenID Connect specs/deployments. If I compare that to the Shared Signals Framework, it is flexible enough to support both push-based and poll-based approaches to event delivery.

I work on a product that supports both SaaS and self-host deployment architectures -- it is an RP. When self-hosted, a customer seldom exposes any endpoint to the Internet. However, more often than not, customers use cloud-based/SaaS identity providers.

Is there any consideration for how OP commands could support such an architecture without a direct OP-to-RP connection?

(FWIW, we currently have a similar issue when supporting SCIM for self-hosted customers and cloud-based IdPs. For Entra ID, they use the Microsoft Entra provisioning agent to proxy the requests.)

[dickhardt]

Currently the identity of the RP is determined by the command_endpoint URL

Would you elaborate on the use case when self hosted?

There are now numerous services that let you expose a public endpoint that is touted to a self hosted server -- why are those not suitable?

What redirect uri is being used?

[simon-canning-octopus]

There are now numerous services that let you expose a public endpoint that is touted to a self hosted server -- why are those not suitable?

Our self-host customers typically don't expose any endpoints of our product to the internet. Whilst there are solutions available, exposing even a subset of endpoints brings in additional security considerations/requirements that need to be addressed. (E.g., DDoS protection, rate limiting, etc.).

Our product is a CD tool (as in CI/CD) and due to the nature of what it does, it typically sits deep in the network. It has agents it connects to (or that connect to it) to perform production application updates.

What redirect uri is being used?

The user-agent/browser is typically sitting on a private internal network, (VPN/VPC), so a callback URL that is accessible to the browser, but not the OP is used. E.g., https://myservice.internal.example.com/openid/callback.

[dickhardt]

Thanks for the additional information.

What use cases are you considering OP Commands would address for you?

[simon-canning-octopus]

Broadly, I anticipate the account commands to manage account lifecycle states. The cases where access needs to be revoked, or changed in near-real-time are most interesting. Consider the scenario where a developer changes teams and their permissions to deploy one set of applications needs to be revoked and replaced with a new set. We already send similar commands/events via an internal message bus from our IdP for our SaaS implementation today.

I see the tenant commands as less interesting, except for the metadata that helps establish the capabilities of the RP.

Is there a use cases doc that outlines some broad use cases the authors are focused on? I just had another look at CAEP and wonder for the session-related changes if it's a better fit?

[dickhardt]

Broadly, I anticipate the account commands to manage account lifecycle states. The cases where access needs to be revoked, or changed in near-real-time are most interesting. Consider the scenario where a developer changes teams and their permissions to deploy one set of applications needs to be revoked and replaced with a new set. We already send similar commands/events via an internal message bus from our IdP for our SaaS implementation today.

Would you explain more about your IdP and how that fits in? Is it part of an IdP chain where your IdP acts as an RP? If so, perhaps your IdP is where OP Commands would be sent?

I see the tenant commands as less interesting, except for the metadata that helps establish the capabilities of the RP.

I don't expect much usage of the tenant commands except for metadata and audit_tenant -- they complete the tea set for that that care.

The unauthorize command may also be useful.

Is there a use cases doc that outlines some broad use cases the authors are focused on?

No specific doc at this time, but supporting all the IPSIE identity lifecycle levels is a goal https://github.com/openid/ipsie/blob/main/ipsie-levels.md

I just had another look at CAEP and wonder for the session-related changes if it's a better fit?

CAEP is a good fit for session lifecycle. See that section in ISPSIE levels.

---

Your use case is interesting and a useful data point. Thank you for sharing.

As an author, I'd like to see more use cases for a pull mechanism before exploring adding support to OP Commands. It brings up some challenges such as how does the OP identify the RP.

We will leave this issue open so that others that have similar use cases can chime in.

[simon-canning-octopus]

Would you explain more about your IdP and how that fits in? Is it part of an IdP chain where your IdP acts as an RP? If so, perhaps your IdP is where OP Commands would be sent?

For SaaS-based, yes, it's part of an IdP chain. External IdPs (Okta, EntraID, etc.) connect to our auth service which acts as an RP to them, but it also acts as an OP/IdP to the downstream application.

I don't expect much usage of the tenant commands except for metadata and audit_tenant -- they complete the tea set for that that care.

The unauthorize command may also be useful.

That aligns with my thoughts as well.

No specific doc at this time, but supporting all the IPSIE identity lifecycle levels is a goal https://github.com/openid/ipsie/blob/main/ipsie-levels.md

Glad to hear you have that in mind, I'm tracking IPSIE too. I'm expecting it to provide clarity for me as an RP to be able to discuss with customers a clear definition of what can and can't be provided, and is more granular than 'OIDC support', 'SAML support', 'SCIM support', 'OP Commands support' etc.

As an author, I'd like to see more use cases for a pull mechanism before exploring adding support to OP Commands. It brings up some challenges such as how does the OP identify the RP.

Thanks for the discussion -- that's perfectly reasonable. Part of my motivation for opening the issue is to understand how others are thinking about this.

[adeinega]

It brings up some challenges such as how does the OP identify the RP.

An OAuth client (at an RP's side) can use its JWK to generate and sign an assertion similar to assertions RFC7521 which are used for client authentication. This will work for confidential, and public clients as well.

When a client doesn't have JWK, it can still use its client_secret for the client_secret_jwt authentication method per https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication. While this may considered to be less preferred nowadays, it remains to be a valid option.

I’m sure there will be additional options, these two just came to mind immediately (hence sharing them here).

I also left pretty much the same ask in the WG mailing list https://lists.openid.net/pipermail/openid-specs-ab/2025-March/010652.html.

[dickhardt]

The client is not public if it has a JWK

There are of course ways to assert the client identity -- the only requirement we have currently is registration of the command endpoint with the client id

[adeinega]

@dickhardt, let me rephrase this a bit. I referred to all those clients that do not have client_secret but have JWKS. For instance, the specification OpenID Connect Dynamic Client Registration allows us to register native clients with the JWK Set (JWKS) passed by value (not sure if this makes native clients confidential as native clients by definition are public).

[dickhardt]

Hard to imagine why an OP would manage accounts with a single install of a native client registered with Dynamic Client registration.

[adeinega]

@dickhardt, sure, nobody needs to manage accounts directly on a native client, but a native client might still need to receive other OP Commands. For example:

1. an OP might have a strong reason to ask a native client to re-authenticate a user (say in response to a RISC event). This would provide a better user experience than silently invalidating all previously issued access tokens, which isn't great.
2. a native client might want to retrieve information about other users in an Org for its own purposes.

I didn’t want to place too much emphasis on native clients or steer the discussion in that direction. My main point is - there are different ways for an OP (or AS) to authenticate its clients, regardless of their type. That is not an impossible challenge.

If we establish (enough) extensibility points in the specification and a mechanism for delivering OP Commands to clients - even those not directly "reachable" by the OP, we’d unlock a wide range of additional use cases.

[dickhardt]

I'm a fan of opinionated specifications that simplifies implementation and interop.

I'm also a fan of extensibility. I'm not a fan of defining something because it might be useful -- only if there are a large number of use cases where it would be used.

If we have a number of ways for the client to authenticate, that optionality impedes interop and complicates implementation.