Jeff, Jijie, all, Jeff, this is a useful distinction, and I think it exposes a real role collision in the current text. I read RFC 7523 §3 a little differently on one point: it allows `sub` in an authorization grant to identify either the resource owner or an authorized delegate. An agent can occupy that slot, but only if the profile says clearly which mode is in use.
There is also a concrete mismatch we can fix now. AIC-JWT §5.2 defines the DA payload with `agent_id`, `principal`, `requested_lifetime`, `ts`, and `nonce`, but without RFC 7523's required `iss`, `sub`, `aud`, and `exp`. Section 10.2 then presents that DA as an RFC 7523 `jwt-bearer` grant, so those sections do not interoperate yet. I would fix the assertion first, then define the issued token by mode. In `representative` mode, the resource owner or principal is `sub`, and the agent is `act` or `client_id`. In `authorized` mode, the agent may be `sub`, with the signing authorizer carried separately. If the accountable operator is neither party, it needs a third binding. Omri's current token-exchange draft already separates the exchange subject from the requesting party and may be a useful model. Best, Dr. I., _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
