- changed title to [Federation] Evaluation order of custom metadata policy operators
[Federation] Evaluation order of custom metadata policy operators
The document specifies the evaluation order of the standard operators. What if one adds a custom operator ? Can it be inserted anywhere in the ordered list of are there restrictions as to where they can be added.
To begin with I think the evaluation order of the standard operators are fixed and can not be modified.
I also think that value must come first since it ‘over rides’ any other operator and that essential should come last since you would like to have the result of applying all the other operators before evaluation essential.
My proposal is that:
- The evaluation order of the standard operators are fixed and can not be modified.
- Custom operators MUST be placed after the value operator in the evaluation order
- Custom operators MUST be placed before the essential operator in the evaluation order
Comments (8)
-
-
1.
The order of the std operators is indeed fixed per spec and additional operators cannot change it.
(the spec uses the term additional operators, which the language in OIDC for scopes and claims other than the default)
6.1.3.1.1. value
…
Order of processing: First
…
6.1.3.1.2. add
…
Order of processing: After
value
.…
Do you think we should add additional text?
2.
When additional (custom) operators are present, I support the proposal to require
essential
be always last. This could be specified in the section on additional operators:https://openid.bitbucket.io/connect/openid-federation-1_0.html#name-additional-operators
About requiring
value
to be always first, I’m not sure about that. Do you remember the discussion we had several months ago for a specialnested
orjson_query
operator, to indicate the metadata parameter is in a nested JSON object, or to use a JSON query to resolve the metadata parameter? If such an additional operator gets defined, it ought be run first, to obtain the metadata parameter, and then proceed with the modifier / checks operators."framework.xyz.param_1": { "nested": true, "value": "apples-123" }
-
Actually, we could say this:
- Additional operators that perform value modification on metadata parameters MUST always be applied after
value.
- Additional operators that perform value checks on metadata parameters MUST always be applied before
essential
.
This will enable operators like the proposed
nested
which does neither modification nor checking to work as intended. - Additional operators that perform value modification on metadata parameters MUST always be applied after
-
reporter I like that !
-
- changed status to open
-
-
- changed milestone to Implementer's Draft
-
- changed status to resolved
- Log in to comment
Tagged issue title