Usage of "resource" request parameter incompatible with oauth-identity-chaining

[randomstuff]

oauth-identity-assertion-authz-grant is expected to be a profile of identity chaining:

Identity Chaining intentionally leaves many details unspecified in order to support multiple use cases. This specification profiles it [Identity Chaining] […]

However, their definition of the resource parameter in the token Exchange Request is incompatible:

• For identity chaining, this identifies the authorization server for trust domain B (i.e. the resource authorization server)
• For identity assertion authz grant, this identified the resource server

---

In identity chaining, we have:

Token Exchange Request

[…]

resource, URI of authorization server for trust domain B

In oauth-identity-assertion-authz-grant:

The Client makes a Token Exchange [RFC8693] request to the IdP Authorization Server's Token Endpoint with the following parameters:

[…]

resource: OPTIONAL - The Resource Identifier of the Resource Server as defined in Section 2 of [RFC8707].

---

I would claim oauth-identity-chaining is more consistent with the definition of resource because as per RFC 8693, they are supposed to have the same semantic meaning.

[mcguinness]

Identity Chaining draft-19 (latest) says

One of resource or audience is REQUIRED to indicate the intended authorization server in trust domain B.

https://www.ietf.org/archive/id/draft-ietf-oauth-identity-chaining-16.html#section-2.3.1

My read was ID-JAG profile MAY use audience to identify the RAS in token exchange request parameter and allow resource to be the Resource Identifier of the Resource Server. ID-JAG does allow an IdP specific identifier for the RAS which may be considered as a logical identifier.

@aaronpk what is your take here?