Claims appearing both in metadata and metadata_policy within one entity statement

Stefan Santesson

Just adding some rationales here why I think this update is very important.

Say that a TA creates an Entity Statement for an Intermediate Entity A (IE A) that in turn has a subordinate Intermediate Entity B (IE B). In this Entity Statement the TA provides the metadata for IE A and a policy that restricts metadata of IE A (subject) and subordinate entities (e.g. IE B)

Following the current logic, the TA can't assign a value for IE A and at the same time a policy for IE B metadata for the same parameter. This is problematic and it is not logical.

Example: Say we implement the “regex” policy value check (that is shown in examples). The contact for IEA is set to John.doe@example.com and in the policy for contacts we set regex = ^[\wÅÄÖåäö][\w\.:, åäöÅÄÖ\/-@_]*$

This is not allowed. I fail to see why. Why does setting a value for IE A prevent me from providing a policy for both IE A and IE B for that parameter?

‌

Processing priority:

I think the processing logic is quite clear from current definitions. The document already states that the policy applies both to the subject and to subordinates, so the subject metadata must be processed through the policy. And that policy may alter som values in the policy. This means that the resolved policy for the subject MUST always be the metadata of the subject, processed through the declared policy for that entity type. There is no other order of processing I can see that aligns with the specification.

‌

Now that also opens the door for another opportunity

If I can have both a metadata claim and a policy without any restrictions, then I can also allow the metadata claim contain the unaltered version of the metadata collected from the entity's Entity Configuration.

This allows me to publish, in the Entity Statement, the unaltered metadata provided by the entity as the metadata claim, then specify the policy that makes the modifications I want to enforce in the metadata_policy. This can be very powerful if you add an existing service that don’t have a .well-known location.

There could be many reasons why it may be hard to get all OIDC services to publish an Entity Statement. E.g. because it would require update to the product they are using, politics or something else. This would make it a whole lot easier to apply the OpenID federation to current services and then to gradually get them to publish Entity Configurations. A RP could become member of the federation and get access to OPs without changing anything in their implementations. They could just offer their metadata to their Intermediary, download resolved metadata of OPs of interest, install it manually and it would all work out of the box.

‌

What needs to be done

Some text describing the metadata claim should be clarified. Making it clear that any data entered here is processed through metadata_policy if present.

The few places that mandates chain validation to start with an Entity Configuration should be updated to allow alternative optional strategies such as using a suitable resolve endpoint or to start with an Entity Statement for the target entity from an Intermediary Entity.

It is the responsibility of the service doing chain validation to determine if the validated data for the target entity is sufficient for their intended interaction with that entity.

2023-11-10T20:36:48+00:00

Comments (4)

Stefan Santesson
Just adding some rationales here why I think this update is very important.

Say that a TA creates an Entity Statement for an Intermediate Entity A (IE A) that in turn has a subordinate Intermediate Entity B (IE B). In this Entity Statement the TA provides the metadata for IE A and a policy that restricts metadata of IE A (subject) and subordinate entities (e.g. IE B)

Following the current logic, the TA can't assign a value for IE A and at the same time a policy for IE B metadata for the same parameter. This is problematic and it is not logical.

Example: Say we implement the “regex” policy value check (that is shown in examples). The contact for IEA is set to John.doe@example.com and in the policy for contacts we set regex = ^[\wÅÄÖåäö][\w\.:, åäöÅÄÖ\/-@_]*$

This is not allowed. I fail to see why. Why does setting a value for IE A prevent me from providing a policy for both IE A and IE B for that parameter?

‌

Processing priority:

I think the processing logic is quite clear from current definitions. The document already states that the policy applies both to the subject and to subordinates, so the subject metadata must be processed through the policy. And that policy may alter som values in the policy. This means that the resolved policy for the subject MUST always be the metadata of the subject, processed through the declared policy for that entity type. There is no other order of processing I can see that aligns with the specification.

‌

Now that also opens the door for another opportunity

If I can have both a metadata claim and a policy without any restrictions, then I can also allow the metadata claim contain the unaltered version of the metadata collected from the entity's Entity Configuration.

This allows me to publish, in the Entity Statement, the unaltered metadata provided by the entity as the metadata claim, then specify the policy that makes the modifications I want to enforce in the metadata_policy. This can be very powerful if you add an existing service that don’t have a .well-known location.

There could be many reasons why it may be hard to get all OIDC services to publish an Entity Statement. E.g. because it would require update to the product they are using, politics or something else. This would make it a whole lot easier to apply the OpenID federation to current services and then to gradually get them to publish Entity Configurations. A RP could become member of the federation and get access to OPs without changing anything in their implementations. They could just offer their metadata to their Intermediary, download resolved metadata of OPs of interest, install it manually and it would all work out of the box.

‌

What needs to be done

Some text describing the metadata claim should be clarified. Making it clear that any data entered here is processed through metadata_policy if present.

The few places that mandates chain validation to start with an Entity Configuration should be updated to allow alternative optional strategies such as using a suitable resolve endpoint or to start with an Entity Statement for the target entity from an Intermediary Entity.

It is the responsibility of the service doing chain validation to determine if the validated data for the target entity is sufficient for their intended interaction with that entity.
- 2023-11-10T20:36:48+00:00
Michael Jones
To be fixed by https://bitbucket.org/openid/connect/pull-requests/694
- 2024-01-30T13:30:03+00:00
Michael Jones
- changed milestone to Implementer's Draft
- 2024-02-01T14:18:04+00:00
Michael Jones
- changed status to resolved
Was addressed by PR #694
- 2024-02-09T20:11:44+00:00
Log in to comment