The constraints parameter in a OP self-signed statement

[Vladimir Dzhuvinov]

Hi Roland,

Are we interpreting the spec correctly that when an OP publishes a
"constraints" in its own statement, that this is meant to indicate what
kind of constraints the OP is going to apply when resolving the trust
chain for an RP that comes to register (auto or explicit)?

https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.section.2.1

Thanks,

Vladimir

[Roland Hedberg]

Hi Vlad,

No!

‘constraints' are part of the policy language.
It is not part of metadata_policy but appears alongside of it (look at the example in section 2.1).

As with metadata_policy it applies to subordinate entities.

As an OP is a leaf entity it doesn’t make sense to have ‘constraints’ in an entity statement published by such an entity.


— Roland

[Vladimir Dzhuvinov]

On 06/07/2020 20:50, Roland Hedberg wrote:
> Hi Vlad,
>
>> On 6 Jul 2020, at 12:28, Vladimir Dzhuvinov <vlad...@connect2id.com> wrote:
>>
>> Hi Roland,
>>
>> Are we interpreting the spec correctly that when an OP publishes a
>> "constraints" in its own statement, that this is meant to indicate what
>> kind of constraints the OP is going to apply when resolving the trust
>> chain for an RP that comes to register (auto or explicit)?
>>
>> https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.section.2.1
> No!

Right :)

> ‘constraints' are part of the policy language.
> It is not part of metadata_policy but appears alongside of it (look at the example in section 2.1).
>
> As with metadata_policy it applies to subordinate entities.
>
> As an OP is a leaf entity it doesn’t make sense to have ‘constraints’ in an entity statement published by such an entity.

I'll explain our reasoning:

When we worked on the trust chain resolver it was realised that a rogue
RP can make a DOS request that resolves to an infinite number of steps.
Such an attack can be implemented with a piece of code that creates an
infinite chain of authority_hints, dynamically.

To prevent such attacks the trust chain resolver got a param to limit
the number of steps in the path. A colleague working on the SDK also
thought that in a more complex federation with a multitude of chains the
admin of the OP could decide to avoid some intermediates, e.g.
temporarily, if they have technical or security issues.

https://www.javadoc.io/doc/com.nimbusds/oauth2-oidc-sdk/latest/com/nimbusds/openid/connect/sdk/federation/trust/TrustChainResolver.html

At present the OP server gets configured with those same params to limit
the number of steps, and even the entity IDs, if desired.

https://connect2id.com/products/server/docs/config/core#op-federation-constraints-maxPathLength

We thought the "constraints" in the OP entity statement could be used to
inform RPs of the OP's own "rules" which are going to apply when the RP
statement gets resolved.

Does this make sense?

Vladimir

[Roland Hedberg]

For the OP to have constraints as to what it will allow regarding the RP’s trust chains, absolutely !!!
No question about it. I have to add some of that to my code.

To have it published, not so sure.

What’s the benefits from the RP’s point of view ?
What would the RP do with this data ?

The reason for section 6.2 (which I’ve on a number of occasions has planned to rip out) was
that the RP could find out what the OP would think about the RP and then by magic adapt to
the result and in some way modify it’s client metadata or not try to register at all.

— Roland

There is nothing you cannot prove if your outlook is only sufficiently limited. (Dorothy L. Sayers, ”Whose body?”)