dickhardt
commented
1 day ago A few points in your comment @mcguinness ;)
- I agree some discovery of what commands the RP will support is desirable. There is also other RP discovery info that could flow on the same call.
Can the RP support different commands for different OPs, or do we keep it simple that the RP supports certain commands for all tenants? On the one hand, it is simpler to have the RP support the same thing for all OPs (which would be the same for multi tenant OPs)
But some features could be gated by what the RP has sold the customer rather than what is implemented. If this is the case, then in discovery the OP needs a way of communicating the tenant so the RP can respond if it is supported.
Tenant identifier is not currently standardized (hd from Google, tid from Microsoft)
The discovery call could return more config than supported commands as well.
A key enterprise scenario this spec should unlock is to enable self-service apps to be authorized to sign-in enterprise users only if they meet the OP contract of "I will give you an
id_tokenif you promise you will process lifecycle commands I send for users that you JIT create/link." The OP wants to only release identity assertions if it can ensure that that is can own the lifecycle of the linked RP account so it can manage the risk of backdoor access that is disconnected from the OPThe
commands_urispecified during client registration is a generic channel for commands and does not specify what commands the client will accept. The presence of this parameter also doesn't explicitly consent to the processing requirements of lifecycle claims needed by the enterprise to ensure account lifecycle is sourced by the OP. This "contract" is what makes this scenario different than shared signals IMHOWe should consider adding a
commands_supportedclient registration parameter so that the OP can ensure that the client meets OP policy requirements for this new contract. OPs can reject clients that don't support the necessary claims.This may not fully address scenarios for multi-tenant OPs where a single client registration is valid for multiple tenants. Some tenants may be different processing requirements (e.g Google personal vs Google workspace domain).
Moving the marker that I accept processing of lifecycle commands to the authorization request would enable more late bound processing such as per-tenant policy but introduces more RP complexity and would more than likely introduce a dependency on request signatures for redirects or backchannel requests (PAR) so that consent couldn't be attacked.
The mental model I have here callback promise pattern. Client is registering a promise during sign-on that the OP can callback when the promise is resolved. In fact maybe it makes sense for this promise to be resolved when a timeout expiry is hit just to ensure that OP can still communicate with the RP. Is it worth to explore this pattern more?
This brings up another side affect of this spec. Currently the RP doesn't need to be IP reachable by the OP. The RP can uses any number of intermediates to make front-channel authorize requests or backchannel token requests. There is no requirement that the RP must be reachable directly by the OP. Commands add a very new constraint on deployment models if the OP is required to be able to directly POST the RP. Logout supports both front-channel and back-channel bindings to address this deployment challenge even though the reality is that front-channel is pretty constrained and doesn't hold up to most real world deployments. SCIM is also introduces a backchannel requirement so maybe we just make this deployment constraint explicit and move on. Adding support for polling similar to SSF/secevents just adds back all the complexity.