Metadata policy

[Roland Hedberg]

Hi!

Based on the discussion we had during the interop event yesterday I think we need to change to

text describing combining and applying metadata policies.

These are my ideas.

If we start with combining. This is about combining 2 metadata policies provided by 2 different entities in a

trust chain. Combining all the metadata policies in a trust chain one starts with the trust anchor and the 

immediate subordinate to the trust anchor then takes the result of that combination and combines that with the

policy defined by the next entity in the trust chain and so on.

There is an example of this in the specification (section 4.1.3.1)

Now there are some policy types that can not be combined.

- subset_of/superset_of and one_of. 

subset_of and superset_of applies to claims that can have a list of

values (for instance contacts) while one_of applies to claims that can only have one value (for instance 

id_token_signed_response_alg).

and then we have 

- value

value overrides everything else. 

So having ‘value' together any other policy type (except for essential) doesn’t make sense.

You also have to make sure that combining 2 policies does not result in something the

is more permissible than what the superior policy allows.

Combining a superiors

id_token_signed_response_alg: {“one_of”: [“ES256”, “ES384”}

with an subordinates

id_token_signed_response_alg: {“one_of”: [“ES384”, “ES512”]}

would result in 

id_token_signed_response_alg: {“one_of”: [“ES256”, “ES384”, “ES512”]}

which is invalid since it allows the value to be taken from a larger set than what

the superior specified.

One also has to make sure that the combination makes sense. Having a default which is 

not part of a one_of set is for instance not OK. Another example would be that a subset_of set 

must be a superset of a superset_of set (parse that sentence :-)).

Once combining the Metadata policies has be accomplished the next step is to apply

the combined policy onto the metadata.

Doing that one follows these steps for each claim in the policy.

1) If there is a ‘value’ statement in the policy apply that and you’re done.

2) Add whatever value is specified in an ‘add’ clause.

3) If the claim still has no value apply the ‘default’

4) Do the essential check. If ‘essential’ is defined to be True then the claim MUST have a value by now.

5) Do the checks. Verified that the value is ‘one_of’ or that the values are ‘subset_of’/‘superset_of'.

Thoughts ?

— Roland

Were it left to me to decide whether we should have a government without newspapers, or newspapers without a government, I should not hesitate a moment to prefer the latter. -Thomas Jefferson, third US president, architect, and author (1743-1826) 

[Vladimir Dzhuvinov]

Hi Roland,

The suggestion makes sense.

We'll implement the steps 1 through 5 in the SDK and will give feedback.

Thanks!

Vladimir

--
You received this message because you are subscribed to the Google Groups "openid-federation-interop" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openid-federation-...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openid-federation-interop/B0528511-4616-4C9D-BCF6-B35A0B1DB36B%40catalogix.se.

-- 
Vladimir Dzhuvinov

[Vladimir Dzhuvinov]

This is from the latest draft 13:

4.1.4. Enforcing Policy

If applying policies to a metadata statement results in incorrect metadata, then such a metadata statement MUST be regarded as broken and MUST NOT be used.

Now, this tells us to drop invalid metadata, and hence report the RP registration as failed.

Shouldn't we also mention that RP registration must also fail when the metadata policy is invalid?

Vladimir

To view this discussion on the web, visit https://groups.google.com/d/msgid/openid-federation-interop/364a84d4-37a8-0803-1502-3e3586ab6a2f%40connect2id.com.

-- 
Vladimir Dzhuvinov

[Roland Hedberg]

Yes !

To view this discussion on the web, visit https://groups.google.com/d/msgid/openid-federation-interop/e499bde5-3c07-fcf9-6265-1dafedfa30e9%40connect2id.com.

[Vladimir Dzhuvinov]

I've been thinking about various bits and pieces concerning the metadata policy.

The policy in a federation turns to be an important part, on par with the automated registrations.

So therefore we want to make the policy keeping free from errors and mistakes, which can lead to failed registrations / login disruptions, security issues, or situations where admins may need to intervene manually.

The policy published by an entity has the following structure:

• it consists of zero or more policy entries
  
  
• each policy entry applies to a metadata parameter, such as id_token_signing_alg
  
  
• each policy entry consists of one or more directives, which can be
  
• parameter mutations
• parameter checks
  

How does the above terminology sound? I would like to suggest to introduce some kind of basic structure and some terminology in the policy spec, to make the language more concise and consistent.

Here I found a policy lang spec that can serve as some inspiration:

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_inheritance_mgmt.html

Given the above structure, and the rules about "value", etc, it turns out that when an anchor or intermediate entity's admin defines the JSON object for an entity's policy, that we have general rules that apply.

My second suggestion is to spell the general rules for creating an individual policy out, so that the policy for an entity can be validated on its own, to be "meaningful" and "clean", when it's being created, and not rely entirely on the logic that gets applied when the policies in a chain get merged.

To illustrate with "value" - to state the rule that when creating a policy entry with the "value" directive there MUST NOT be other directives present.

With such rules for policy entry creation in place we can then encode them into the SDK and thus enforce that only meaningful policies can get fed into an entity statement.

In draft 13 - 4.1.2 Policy Type Combinations - we have much information already, but because it covers all aspects in one place, it may be difficult for an admin for an anchor, admin for an intermediate or for developer to get the exact pieces they need for their job. I have some suggestions for that and will mention them on Tuesday.

Now, if we have a definition of a legal / valid policy for an individual statement, what would happen if we also require that to also apply to a merged / combined policy?

The nice effect is that we'll already have the rules in the spec (and computer code) to validate it. Thus the spec will be freed from having to define additional rules for validating a combined policy and then rules for applying it.

In that case, however, the spec for the algorithm for merging the policies must be defined in a complete way. But this may actually be a good thing!

Vladimir

To view this discussion on the web, visit https://groups.google.com/d/msgid/openid-federation-interop/5F03F9FB-F944-4F7C-9E74-7F7FD6A16705%40gmail.com.

-- 
Vladimir Dzhuvinov

[Roland Hedberg]

I like your thinking! :-)

Best case scenario I have a proposal ready when we meet on Tuesday.

To view this discussion on the web, visit https://groups.google.com/d/msgid/openid-federation-interop/a0793b69-a23e-4030-375b-44e4f96aa2b5%40connect2id.com.

— Roland

It is curious that physical courage should be so common in the world, and moral courage so rare. -Mark Twain, author and humorist (30 Nov 1835-1910)

[Roland Hedberg]

I’ve pushed a modified version of the spec to my GitHub repo.

Two major changes.

1) The metadata policy section is rewritten. I haven’t had time to fix the examples yet.

So the text is low on examples.

2) After lots of discussions I’ve changed references to "client authentication" in connection

with automatic registration to "client verification”. Which is a more correct description

of what we’re doing. We can talk more about this when we meet today.

My code is not yet updated to follow the new version and won’t be for todays exercise.

To view this discussion on the web, visit https://groups.google.com/d/msgid/openid-federation-interop/ABA2EBC9-AEF8-4FFF-B2B1-A118A0C94E28%40catalogix.se.

[Vladimir Dzhuvinov]

Hi all,

On 15/12/2020 09:39, Roland Hedberg wrote:

I’ve pushed a modified version of the spec to my GitHub repo.

Two major changes.

1) The metadata policy section is rewritten. I haven’t had time to fix the examples yet.

So the text is low on examples.

Thanks, I'm already looking at it :)

https://github.com/rohe/oidcfederation/blob/master/draft/openid-connect-federation-1_0.txt

2) After lots of discussions I’ve changed references to "client authentication" in connection

with automatic registration to "client verification”. Which is a more correct description

of what we’re doing. We can talk more about this when we meet today.

This makes sense, esp on the front-end (notPAR) and I remember the discussion we had with Brian about that.

https://bitbucket.org/openid/connect/issues/1195/federation-allow-request_object-auth

-- 
Vladimir Dzhuvinov