Allow trust marks in subordinate statements

[Stefan Santesson]

Section 3. states:

This claim MUST NOT be present in Subordinate Statements. Trust Marks are described in Section 6.3.

‌

This requirement is an unnecessary restriction that prevents legitimate extensibility of the standard.

The standard already makes it possible to convey metadata for the subject in a subordinate Entity Statement

It should be equally possible to provide a list of Trust Marks. The risks are none as the Trust marks are signed and bound to the subject.

‌

The reason for this is to allow extensibility where an end entity is supported even if it does not publish an Entity Configuration. This is possible to support as en extended implementation as the subordinate Entity Statement can carry complete information about the leaf entity if properly advertised. See separate issue.

‌

Even if such extended support is not standardised. It should not be blocked as a voluntary extension marked critical to ensure interop.

‌

‌

[Giuseppe De Marco]

Hej Stefan,

at the time of the italian impl, we decided that the INT that it is also a TM issuer for its subordinates provides the trust marks within the subordinate entity statement.

Meanwhile the specs went ahead, and now we have a more specialized endpoint for doing that: the Trust Mark endpoint (https://openid.net/specs/openid-federation-1_0.html#name-trust-mark-endpoint). It responds to the requirement that the TM issuer is transversal and not directly linked with the trust marked entity, as the INT is with its subordinates. Therefore it definitively is a proper solution in terms of design, since it satisfies all the use cases without any exception.

For new implementations I kindly suggest to use this endpoint, while in italy we provide TM in the subordinates ES for retro compatibility, since the specs doesn’t prevents this and the italian impl profile has defined this in the past.

[Stefan Santesson]

Hi Guiseppe,

I’m not sure, but I think we are talking about two quite different things here.

I think I understand that you adress the process through which a subject of a Trust Mark obtains the Trust Mark from the Trust Mark issuer. This is NOT what this issue is about.

‌

What I try to adress here is: Once you have obtained the trust marks for the target entity (by whatever process you have in place for that), are you then allowed to include them in an Entity Statement for that target entity?

‌

I’m exploring possible workarounds here to support entities that have limited capabilities to do advanced OpeID fed stuff. Things these specific entities may not be capable of doing are:

• Creating and signing Entity Configuration with their federation key
• Publishing Entity Configuration at .well-known location URL relative to their Entity Identifier
• Creating and signing a Trust Mark request to a trust mark endpoint

‌

We see that we can support such endpoints by legitimate extensions to the standard. These extensions makes it possible for resolvers to resolve metadata and trust marks for such less capable entities.

The only requirement that we struggle with in order to allow this extensible support for lesser capable entities, is the requirement discussed in this issue that seems to prohibit declaration of the subjects Trust Marks in an Entity Statement issued for that entity.

‌

[Michael Jones]

When would you want a trust mark in a Subordinate Statement?

[Stefan Santesson]

It comes as a direct consequence of that a chain does NOT have to be terminated with an entity configuration!

Think about it for a second.

If you want to do traditional discovery. That is:

1. Start with an Entity Identifier
2. Find the .well-known location associated with that ID
3. Get the Entity Configuration
4. Build the path to a Trust Anchor you trust.
5. Validate the path
6. Etc.

Following this model, the chain MUST end with an Entity Configuration. But there are other cases.

A resolver can travers the federation tree top down and build paths from a Trust Anchor to all subordinate entities. This by using the list and fetch endpoints of all Intermediates.

These chains do not have to end with an entity Configuration. They could end with a subordinate statement issued to the target entity if it contains all data about the target entity.

BUT!!! Then this subordinate statement MUST be allowed to contain all relevant information about the target entity to generate a resolve response. This includes:

• Metadata (This is allowed today using the metadata claim)
• Trust Marks (This is NOT allowed today)

We enable this option in a controlled and interoperable way by defining a new critical extension claim in the entity statement for the target entity. This critical claim states the following:

• The subject entity does NOT store its own Entity Configuration (So don’t bather looking for it)

  • That is: This subject can therefore only be discovered and validated through a compliant resolver (the .well-known location is not available)

• This subordinate statement contains complete information about metadata and trust marks for this subject.

‌

In our implementation, we allow validation of chains that ends with a subordinate entity statement that contains this critical custom extension claim.

That should be a legal extension of the standard. The claim is critical and those who don’t understand it must fail. So it's safe.

‌

The only problem is that this violates the requirement above. Which does not make any sense.

If a subordinate statement is allowed to carry metadata for the subject, then it should also be allowed to carry information about trust marks. Any thing else is non-logical in my opinion.

I think there is no harm to allow Entity Statements to contain trust marks that is issued for that subject? Why would you make it illegal?

[Michael Jones]

The editors agreed to investigate this for the upcoming Implementer’s Draft.

[Giuseppe De Marco]

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

[Giuseppe De Marco]

Closed by https://bitbucket.org/openid/connect/pull-requests/701

[Stefan Santesson]

I have finally got to the point where I have the time to review all changes. Starting with this one seems OK. I’m happy!