Add comprehensive support for account resolution and management handover #27
Conversation
- Add 'manage' command to Abstract and Introduction command lists - Add account management handover documentation to Command Usage Overview - Add 'aud_sub' claim definition to Command Token section for account resolution - Register 'aud_sub' and 'managed_by' claims in IANA JWT Claims registry - Complete integration of account resolution features throughout specification These changes enable OPs to take over management of existing RP accounts and provide efficient account lookup using RP internal identifiers.
|
|
||
| - `RP` if the account is managed by the RP | ||
| - `OP` if the account is managed by the OP | ||
| - `other` if the account is managed by a party other than the RP or OP |
There was a problem hiding this comment.
may be helpful to make clear that OP should be only be returned when the account is managed by the command token's iss, otherwise if its managed by another OP it should be other (information disclosure) or unknown (RP doesn't want to disclose that its managed by a different OP.
Another topic that would be good for a security consideration section
There was a problem hiding this comment.
agreed
Not just the OP, the tenant of the OP
OPif the account is managed by the OP tenant in the Command
| In scenarios where malicious activity is detected or suspected, OPs play a vital role in protecting end-users. They may need to instruct RPs to revoke authorization or delete Accounts created by malicious actors. This helps contain the impact of unauthorized actions and prevent further misuse of compromised Accounts. | ||
|
|
||
| In enterprise environments, where organizations centrally manage workforce access, OPs handle essential Account operations across various stages of the lifecycle. These operations include activating, maintaining, suspending, reactivating, archiving, restoring, and deleting Accounts to maintain security and compliance. | ||
| In enterprise environments, where organizations centrally manage workforce access, OPs handle essential Account operations across various stages of the lifecycle. These operations include activating, maintaining, suspending, reactivating, archiving, restoring, and deleting Accounts to maintain security and compliance. Additional, enterprises want to take over management of the accounts its employees may have created at an RP. |
There was a problem hiding this comment.
| In enterprise environments, where organizations centrally manage workforce access, OPs handle essential Account operations across various stages of the lifecycle. These operations include activating, maintaining, suspending, reactivating, archiving, restoring, and deleting Accounts to maintain security and compliance. Additional, enterprises want to take over management of the accounts its employees may have created at an RP. | |
| In enterprise environments, where organizations centrally manage workforce access, OPs handle essential Account operations across various stages of the lifecycle. These operations include activating, maintaining, suspending, reactivating, archiving, restoring, and deleting Accounts to maintain security and compliance. Additionally, enterprises want to take over account lifecycle management of the accounts its employees may have created previously at an RP. |
|
|
||
| The OP sends this Command to request a change in management responsibility for an Account. The Command Token MUST include the following additional claim: | ||
|
|
||
| - **managed_by** |
There was a problem hiding this comment.
There is prior art with managedBy in directory sync. AD uses this attribute name to determine which user(s) can manage a group's memberships for example (https://learn.microsoft.com/en-us/windows/win32/adschema/a-managedby)
I think we should be OK just flagging it so we make intentional decision here.
There was a problem hiding this comment.
we are using snake_case everywhere else
|
|
||
| ### Access Denied Error | ||
|
|
||
| If the RP does not allow the OP to change management of the Account, the RP MUST return an HTTP 403 Forbidden response and include the `error` parameter with the value of `access_denied`. |
There was a problem hiding this comment.
The term "allow" seems very broad as there could be other reasons an operation is not allowed such as the management_not_transferable error out have outlined below. This error feels like it should be scoped to authorization only such as RP does not authorize the OP to change management of the Account
|
|
||
| - **aud_sub** | ||
| OPTIONAL for Account Commands. | ||
| The RP's internal identifier for the Account, as provided by the RP during account resolution. When present, the RP SHOULD use this value to identify the Account rather than the combination of `iss` and `sub`. This claim facilitates more efficient account lookup and management at the RP. |
There was a problem hiding this comment.
| The RP's internal identifier for the Account, as provided by the RP during account resolution. When present, the RP SHOULD use this value to identify the Account rather than the combination of `iss` and `sub`. This claim facilitates more efficient account lookup and management at the RP. | |
| A JSON string. The RP's internal identifier for the Account, as provided by the RP during account resolution. When present, the RP SHOULD use this value to identify the Account rather than the combination of `iss` and `sub`. This claim facilitates more efficient account lookup and management at the RP. |
|
|
||
| - **aud_sub** | ||
| OPTIONAL for Account Commands. | ||
| The RP's internal identifier for the Account, as provided by the RP during account resolution. When present, the RP SHOULD use this value to identify the Account rather than the combination of `iss` and `sub`. This claim facilitates more efficient account lookup and management at the RP. |
There was a problem hiding this comment.
RP should only use this identifier if the account is currently owned by the OP IMHO as this basically opening door for account takeover attacks. This is good candidate for security considerations section. OP should have to take over management of the account if it wants to be authorized to use this identifier. This ensures that RP doesn't accidentally allow an OP to sign a user that isn't owned by the OP. Alternatively the RP should need some configuration to explicitly allow this behavior for an OP that isn't the owner and audit/etc.
There was a problem hiding this comment.
The RP is only going to allow an OP to manage accounts that are in the RP that allow the OP tenant to manage. For example, accounts with emails in the domain the OP tenant owns.
The RP needs to communicate the aud_sub to the OP if the RP is not going to be using the sub to identify the account -- otherwise how will the OP tell the RP which account to manage
| ## Success Response | ||
|
|
||
| When an RP successful processes an Account Command, the RP returns the `HTTP 200 OK` response and a JSON object containing the provided `sub`, and the `account_state` set to the state of the Account after processing. | ||
| When an RP successful processes an Account Command, the RP returns the `HTTP 200 OK` response and a JSON object containing the following claims: |
There was a problem hiding this comment.
| When an RP successful processes an Account Command, the RP returns the `HTTP 200 OK` response and a JSON object containing the following claims: | |
| When an RP successfully processes an Account Command, the RP returns the `HTTP 200 OK` response and a JSON object containing the following claims: |
| OpenID Connect defines a protocol for an end-user to use an OpenID Provider (OP) to log in to a Relying Party (RP) and assert Claims about the end-user using an ID Token. RPs will often use the identity Claims about the user to implicitly (or explicitly) establish an Account for the user at the RP | ||
|
|
||
| OpenID Provider Commands complements OpenID Connect by introducing a set of Commands for an OP to directly manage an end-user Account at an RP. These Commands enable an OP to activate, maintain, suspend, reactivate, archive, restore, delete, audit, and unauthorize an end-user Account. Command Tokens build on the OpenID Connect ID Token schema and verification, simplifying adoption by RPs. | ||
| OpenID Provider Commands complements OpenID Connect by introducing a set of Commands for an OP to directly manage an end-user Account at an RP. These Commands enable an OP to activate, maintain, suspend, reactivate, archive, restore, delete, audit, and unauthorize an end-user Account, and take over management of an existing account. Command Tokens build on the OpenID Connect ID Token schema and verification, simplifying adoption by RPs. |
There was a problem hiding this comment.
It might be useful to define what "take over management" means. The document currently doesn't prescribe any behaviors for an user that is managed
There was a problem hiding this comment.
yes -- per other note -- is it session or identity life cycle
- Add comprehensive Management Transfer section with manage command details - Separate Account Resolution and Management Transfer into distinct sections - Update Introduction with 'account lifecycle management' terminology - Clarify Success Response with 'OP tenant' specification - Add JSON String type specifications for callback_token and aud_sub claims - Include granularity comment about lifecycle vs session management - Fix typo: 'successful' -> 'successfully' in Success Response - Various editorial improvements for clarity and consistency Addresses suggestions from #27 Co-authored-by: collaborator from original PR review
These changes enable OPs to take over management of existing RP accounts and provide efficient account lookup using RP internal identifiers.
#25