How to treat unknown identifiers in claims parameter
Issue #1094
closed
The RP might use identifiers for trust frameworks, id documents or verification methods that the OP does not understand. What is the best way to cope with such a situation?
- ignore the error and provide the RP with what is available
- refuse the request with an error
Comments (6)
-
-
- changed status to open
Try to find Must Understand in JWx.
-
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.
-
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.
-
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.
-
reporter
- changed status to closed
- Log in to comment
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.