Trust in the resolver

[David W Chadwick]

The current text states “The security trust model changes…(from trusting no one except the Trust Anchor to)… trust in the resolver to perform the validation of the cryptographically protected metadata correctly and to provide it with authentic results.” However, if there is a direct trust chain from the resolver to the trust anchor (with no intermediares), it should be possible to indicate that the trust anchor trusts the resolver to perform the validation of the cryptographically protected metadata correctly and to provide clients with authentic results. Then the trust model of the resolver’s clients would not change. Clients would still only need to trust their trust anchor.

This could be engineered in different ways, which is open for discussion. For example, we could define a trust mark “trusted resolver” which a trust anchor could award to a trusted resolver. Or we could possibly define a metadata component and type that indicates the protocol for interacting with a trust anchor and that the resolver could use in its Entity Configuration Statement, and the trust anchor in its Entity Statement for the resolver, to indicate this type of trust.

The question to be addressed is this. Is it more realistic to expect numerous clients to know how to determine if a resolver is trusted, or to expect the trust anchor to be capable of determining this.

‌

[Giuseppe De Marco]

Is this issue intended to remark how the trust to a specific trust resolver (that serves the entity resolve endpoint) may be certified with a trust mark?

Do you think that a non normative example in the Trust Mark example section may sound interesting?
As we now Federation 1.0 enables the Trust Marks but it doesn’t mandate their usage

[David W Chadwick]

I would like us to discuss this issue on the next call, in particular the question that I think should be addressed. To put it another way, how to make it simpler for thousands (millions?) of entities to only need to trust the trust anchor, and not the resolver.

[Giuseppe De Marco]

From my experience a participant must trust both trust anchor and the other party

An OP trust an RP because this latter Is trusted by trust anchor

An RP trusts an Op for the same reason

Two parties Is not enough to establish the trust, 3 Is the perfect Number: requestor (rp), TA and endpoint (Op)

‌

[Michael Jones]

On the 26-Sep-22 working group call, we agreed that we should discuss this during the next Europe-friendly call.

[Giuseppe De Marco]

@David do you have a concrete proposal to improve the text?
We discussed this issue without have found something to add as recommendations or regulatory text to cover this in the current draft.

please if you can push your suggestion here in the issue, we’ll take care of this with priority

[Roland Hedberg]

To me there is a difference between doing something your self or leaving it to some else to do it for you.

If the other party is trusted by the Trust Anchor or not doesn’t change that.

It’s been pointed out that if an audit is made, telling the auditor that you didn’t do something but let someone else do it for you is not a good answer. So I don’t think your proposal adds anything.

[David W Chadwick]

“doing something your self or leaving it to some else to do it for you” is the difference between direct trust and transitive trust. An entity has direct trust in the trust anchor but everything after that is transitive trust. So the federation model already supports transitive trust, in that the trust anchor says who its subordinate is, and it says who the leaf entity is. And you trust this. You are leaving it up to the trust anchor to say who its subordinates are, and up to the subordinates to say who the leafs are. You are not doing this yourself. You are leaving it up to others to do it for you. So if the trust anchor says ‘this is my resolver that I trust to resolve entities correctly’ this is no different (in a direct/transitive way) from the trust anchor saying ‘this is my subordinate that I trust to identify its subordinates correctly’. Whilst WHAT you are trusting the trust anchor for is different, the mechanism for trusting is the same. Federation cannot operate without transitive trust. So it is not possible for every entity to perform direct trust itself (i.e. do everything itself).

“telling the auditor that you didn’t do something but let someone else do it for you is not a good answer.” So if I use an accountant to do my company accounts, and the Revenue sends an inspector around who finds my accounts are faulty, then saying that I paid an accountant to do it for me is not a good answer? Businesses would surelly grind to a halt if the owners always had to do the accounts (and everything else) themselves.

[David W Chadwick]

Guiseppe, I am informed that all browsers now use their own DNS resolvers and wont let the user configure the browser to use a different resolver. In other words, browsers trust their own resolvers and do not want to use any other ones. So if a trust anchor has its own resolver that it trusts, then it should be able to inform other entities in the federation that this is my trusted resolver, and an entity can then decide to either implement its own resolver or use the trust anchor’s resolver. Since an entity already trusts the trust anchor (by definition) then by transitive trust it can trust the resolver (if it is a separate entity to the trust anchor) or the resolve endpoint of the trust anchor if that is available to the federation.

[David W Chadwick]

Here are my concrete proposals.

First define direct trust and transitive trust and give examples of how each are used in the specification. (Guiseppe your example of the OP trusting the RP is transitive trust).

Then differentiate between the trusting mechanism (i.e. direct and transitive trust) and WHAT is being trusted ie. what kind of trust this is; what do you trust the trust anchor to do (identifying subordinates, identifying trust mark issuers, identifying trusted resolvers).

Then finally you can explain that by transitive trust (via the trust anchor) an entity can determine who are the trusted trust mark issuers, trusted subordinates and trusted resolvers. Every entity can then decide which of these kinds of trust it is willing to place in the trust anchor. There is no requirement for an entity to trust a trust anchor for anything or everthing. It must decide what kind of trust to place in the trust anchor

[Giuseppe De Marco]

Thank you David, I found very interesting the concept of direct vs transitive trust.
Here my points:

1. If you can suggest here in this thread the text to be included in this section “https://openid.net/specs/openid-connect-federation-1_0.html#section-7.2.3“ I will endeavor to handle it with care for its inclusion within the specifications
2. In “an ideal world” the resolver should be a participant of the federation, so it should be trusted (transitively) because it should onboarded directly by TA or an intermediary
3. The purpose of the specification is decidedly technical and with sections that explain the rationale behind the choices and features. Given the purely technical aims of the specification and the dimensions it has acquired (Federation is really big ... maybe too much) I believe that to produce further discussions on Federation we could support the publication of scientific articles or other documents (medium post .. .). Having said that, if we managed to summarize this further contribution in the previous section, we could manage to include it, otherwise let's focus exclusively on the alleged criticalities of the text and produce literature outside the Spec

last but not least, I am really grateful to you for the time and mind you are spending on Federation too, thank you very much David

[David W Chadwick]

Here is the suggested replacement text for section 7.2.3.

The basic assumption of this specification is that an entity should have direct trust in no one except the Trust Anchor and its own capabilities. However, entities also have to have transistive trust in other entities. For example, the trust anchor states who its subordinates are, and entities have transitive trust in the subordinates to say who their subordinates are, recursively, until the leaf entity is reached.

If an entity’s trust anchor says who its resolver is, then the entity can have transitive trust in the resolver to perform the validation of the cryptographically protected metadata correctly and to provide it with authentic results.

[Roland Hedberg]

I agree with you first section on direct trust in the Trust Anchor and transitive trust in subordinates but I think you compare blueberries and lingonberries. Trusting a subordinate is quite different from trusting a resolver. A subordinate provides you with one piece of the trust chain and leaves the rest to you, a resolver on the other hand collects trust chains, verifies them, applies polices and then presents you with the result.

Having the Trust Anchor vouch for a resolver means something in the context of the federation but if we concern ourselves with auditors they are most likely not members of the federation in which case the fact that the Trust anchor vouches for the resolver means little.

If a federation you manage lets the Trust Anchor issue trust marks that represents trust in a resolvers, you can already do that using what's in the specification. All the necessary pieces are there. But I’m hesitant to write this into the specification because we might open a can of worms if we do. So I’d rather leave it to be specified in a profile document.

[David W Chadwick]

As I said above there are two separate issues, How trust is propogated, and What trust is propogated. I am glad we agree on the first of these, that it is transitive trust that propogates it from the trust anchor to other entities.

The only remaining issue is what trust is being propogated. So I propose we add more text to explain the different types of trust that there is i) trust in subordinates to correctly identify their subordinates and publish correct entity statements about them ii) trust in trust mark issuers to audit the entities they award trust marks to, to confirm that they conform to the rules of the particular scheme iii) trust in resolvers to follow trust chains (which depends upon i) ) and check with trust mark issuers (which depends upon ii) and to apply policies correctly. So it seems to me that the only additional trust that a relying party is placing in the resolver is to apply the policies correctly

[Giuseppe De Marco]

dear friends, the PR below aims to resolve definitively this thread
https://bitbucket.org/openid/connect/pull-requests/332/chore-federation-resolve-endpoint-and

Please do your kindly revisions and, where necessary, add your notes with punctual proposals in the current text

‌

[Giuseppe De Marco]

Closed by https://bitbucket.org/openid/connect/pull-requests/332/chore-federation-resolve-endpoint-and