I would like to bring up one more argument to keep the assertion, client_assertion_type and client_assertion parameters in core.
If I understood correctly, the main argument to remove them from core was that they are underspecified and extensions are needed anyhow before they are useful. First of all, this is not true for client_assertion_type and client_assertion. A client can acquire assertions from an IdP that works intimately with the client. In this case the client knows how to get a client assertion and then how to present it to the Authorization Server, but it really does not need to know anything more. The IdP and the Authorization Server do need to agree on format and keys, but not the client. I agree that this is a less used use case, and that currently there are no implementations to point at (as far as I know), but there is another reason to keep these parameters in core. The assertion parameter was in core, but it was removed and now it is defined by SAML 2.0 Bearer Assertion Grant Type Profile. What will the next assertion extension do, let's say JWT? It can either re-define the assertion parameter or it can reference SAML 2.0 Bearer. Does re-defining imply registration as well? How would that work? Having JWT depend on SAML does not make much sense. While the above issue is minor, I think it would be useful if core defined these parameters as extension points. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
