Add Authorization Server policy section about "Reuse of a Client Attestation JWT"

[Macke]

It would be beneficial to describe that the Authorization Server can also decide whether to accept or reject a Client Attestation JWT. It might also be beneficial to describe the AZ error response if a request is rejected based on Authorization Server policy.

[tplooker]

IMO this is probably worthwhile documenting in section 6 along side the validation rule OR we could opt for a seperate implementation consideration. Given this isn't the first form of client authentication in OAuth im reluctant to define a specific error type for this method of client authentication failing. Typically client configuration and authorisation server metadata makes it clear what is supported and required.

[Macke]

Just for context I am thinking about a scenario where the Authorization Server has additional contextual information that means they wish to force the client to get a fresh Client Attestatiuon JWT before the expiry time is reached. It is certainly possible to do that by using one of the existing OAuth error responses in RFC6749 but none of them really reflect that scenario and I don't think that client configuration or server metadata is granular enough. If this scenario is to be supported it might be better to be explicit that the client should request a new attestation. Note OAuth 2.0 does allow for new error codes to be defined in https://www.rfc-editor.org/rfc/rfc6749.html#section-8.5.

[tplooker]

@Macke with regard to defining an interoperable error type would you mind reviewing #112 for this too as we have introduced the invalid_client_attestation error type?

[Macke]

I like it