Behaviour for bad claim_token_format values

[mrpotes]

If a client submits an unsupported claim_token_format (or the claim_token doesn't conform to that value), what response should the AS return? Do we need invalid_claim_token and unsupported_claim_token_format error codes? We could revert to 6749's invalid_request, but that's not terribly helpful.

[ciseng]

Given other submitted issues, I feel the error responses need to be explained further in the document. I would suggest using 6749’s error response; and adopt “invalid_request” and use error_description to explain further (e.g., error_claim_token_format).

[xmlgrrl]

It doesn't seem helpful to leave unstated what to do! Some obvious choices:

• Option 1: Explicitly adopt _invalidrequest using the rationale that the claim token is the invalid parameter by virtue of an invalid format, and recommend (or mandate?) an error description explaining the problem.
• Option 2: Create a custom UMA error for this condition.
• Option 3: Returning a need_info error with required_claims and claim_token_format

Discussion: Leveraging an error that OAuth gives us would be ideal, but using invalid_request and having to dip into the error_description level seems unfortunate because it stomps on the "user space", so to speak. Then again, we have already invented need_info and it has a way to convey the need for a specific claim token format. All the fields inside required_claims are optional, so returning claim_token_format alone would be a pretty pointed way to convey what's needed.

I'm kind of liking Option 3. If others do too, would we have to say something explicit about it in the spec?

[xmlgrrl]

For completeness's sake, note that decision was made in UMA telecon 2017-08-08. Also implicitly confirmed in UMA telecon 2017-08-17.