How to treat unknown identifiers in claims parameter

Michael Jones

For extensibility, we typically say that fields that are not understood MUST be ignored. That way new things can be added without breaking existing deployments.

Of course, if a field is required and must be understood to meet the use case requirements, then it’s reasonable to return an appropriate error if the required field is present but the value isn’t understood. This kind of handling might be appropriate for the requested trust framework parameter.

2019-06-06T17:21:23+00:00

Nat Sakimura

changed status to open

Try to find Must Understand in JWx.

2019-07-18T14:44:58+00:00

gffletch

By default today, IDP’s would ignore anything they don’t understand. The question is, should we add a “must understand” concept / qualifier to section 5.5.1 of the OpenID Connect spec.

2019-07-18T14:45:25+00:00

Michael Jones

JWS has the “crit” header parameter, which is defined at https://tools.ietf.org/html/rfc7515#section-4.1.11. If we do something to require understanding some extensions, we should parallel that.

2019-09-12T14:24:58+00:00

Victor Herraiz

In our implementation we have to provide a way to force the OP to understand some claims. We do not want to release partial or invalid information to RP, those responses are not valid for the RP and there is no point to provide user info that is not going to be use. At the moment we are thinking on `“must_understand”: true` member at claim level. Extending “crit” could be a little difficult for claims in my opinion.

2019-10-09T08:55:10+00:00

Torsten Lodderstedt reporter

changed milestone to Amendment

2020-01-15T15:46:15+00:00

Torsten Lodderstedt reporter

removed component
assigned issue to

Marcos Sanz
marked as enhancement

Marcos

2020-01-15T18:30:15+00:00

Marcos Sanz

If I understand correctly the initial content of this issue:

We are talking exclusively about requests RP towards OP and how OP should react on unknown values for some elements (not the other way around)
Affected elements are trust_framework, evidence/type, evidence/method and evidence/document/type (those allowed to be specified in a query as of section 5.3)

Assumptions:

We want to design for extensibility (new values for aforementioned elements unknown to us at the moment might be defined in the future)
We don’t want to change the query syntax laid down in Core 5.5.1 (i.e. usage of “value” and “values”)
Principle of Least Astonishment should apply

Thoughts:

It’s an invitation for disaster for the OP to ignore query constraints on verification data just because it doesn’t understand them and to return to the client whatever results it finds modulo the unknown constraints, since

a) Results are not what the client asked for.

b) Even if the returned verified_claims would include the real values for trust_framework, evidence, etc that apply for the given result, the client might ignore these data pieces in the belief they match what it was asked for.

c) Generally speaking it’s not a good practice to ignore unknown constraints in a query since it’s left as a trial-and-error game for the client to find out which were the ones understood by the server and which weren’t.

Further, Core 5.5.1 about query syntax says “the value of the value member MUST be a valid value for the Claim being requested.” (similar text for the “values” array). The capitalized “MUST” reminds this is about interoperability, and if the condition of the normative language is not met, it’s fine, even expected, for the processing entity (OP) to return an error.

Now a pragmatic view: if a client really asks for a given framework/evidence type/verification method/document type, it probably is doing so for good business reasons, otherwise it could ask without restriction for any of these and filter whatever results are coming back. Even if it’s true that the OP announces metadata (section 7) about supported values of said elements, it’d be serving protocol efficiency for an OP to be able to make a differentiation at request time between “I know what you mean but I don’t have that data” and “I don’t know what you mean at all”, so that the client can react to the response accordingly.

Finally I don’t think it’s necessary to resort to the “crit” (or crit-like) header parameter to find a satisfactory solution. It would make it more complicated (processing of data at this step is not in occurring header-land) and it might even be unappropriate (this issue is not about claims that need to be understood, but about claim values).

Thus my recommendation:

Dedicated OP errors of the “xyz_not_supported” kind.

If there’s consensus, I’d make a text suggestion and a pull request.