[Federation] Evaluation order of custom metadata policy operators

[Roland Hedberg]

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

‌

[Vladimir Dzhuvinov]

Tagged issue title

[Vladimir Dzhuvinov]

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 special nested or json_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"
}

‌

[Vladimir Dzhuvinov]

Actually, we could say this:

1. Additional operators that perform value modification on metadata parameters MUST always be applied after value.
2. 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.

[Roland Hedberg]

I like that !

[Vladimir Dzhuvinov]

PR here: https://bitbucket.org/openid/connect/pull-requests/722