Federation Figure 5

[David W Chadwick]

Figure 5 is confusing because the Leaf's Entity Statement is published by the Intermediate entity but the figure does not suggest this. The Fetch endpoint fetches the Entity Statement of the subordinate role and not of the role itself, which the diagram suggests.
Suggested changes to Figure 5.
i) Leaf role trust chain entity, change Entity Configuration -> Entity Statement
ii) the Fetch Endpoint arrow should point diagonally down to the role below it in the third column
iii) There should be no arrow from the leaf well-known column to the trust chain column
iv) The trust anchor's entity statement should indicate that it is self-signed and is about itself

‌

[Giuseppe De Marco]

Ciao David!

1. a Leaf publish its self-issued Entity Statement, that’s called Entity Configuration.
2. not sure to for this, I’m providing you a link with the editable source for get clarifications with examples
3. the arrow means (and can be further improved, yes!) that from the EC is obtained the URL of the fetch endpoint where the entity statements (subordinate statement) is made available
4. the TA’s self-signed entity statement is the entity configuration, and it is in the column of the entity configurations

here’s the editable source) for any contribution. I’m the author of the figure, I’m prone to resolve all your concerns.

‌

[David W Chadwick]

Hi Giuseppe.

1. Yes but the superior publishes the trusted entity statement of the leaf as I understand it. So it is this that is trusted, not the configuration data.
2. thanks, I am having a go. But I cannot delete anything that I add or that it there already!
3. I understand this
4. Interestingly they have different contents, which implies that a configuration is different to an entity statement (and will be obtained from different places, well known vs fetch endpoint)

‌

[David W Chadwick]

2. Getting resolved by altering screen resolution. I am working on a laptop and not all the instructions were immediately visible and they were not scrollable. I am having to zoom out to see the instructions. But delete not working on my Mac

[Giuseppe De Marco]

Thank you for sharing this. My notes below:

‌

[Giuseppe De Marco]

the current lines in the specs makes sense to me because:

• the first column contains the roles: TA, INT and Leaf

• the second column contains the endpoint where the EC is taken, pls note that the EC is the self-signed entity statement related to its issuer. From this EC, within the federation_metadata, the url of the federation_fetch_endpoint is made available

• the third column represent the statements that forms the trust chain. We have the entity statement ending with the entity configuration of the subject (leaf) of the trust chain

‌

[David W Chadwick]

As I understand it from the current text, only intermediates and anchors have fetch endpoints, since leaf entities do not have any subordinates. So these can only be used for going down the chain from the trust anchor to subordinates. So it is the authority hints that will be used to determine who the superiors are when working up the chain to the anchor. The third column must therefore be the entity statements obtained from the superiors fetch endpoints, and must be for subordinate entities, not for the entity whose fetch endpoint this is. This is why my proposed arrows point downwards

[David W Chadwick]

Or to put it another way. What does a requestor get when it interrogates the fetch endpoint of the intermediate entity? Ans. The entity statement of the leaf entity. (Unless I have completely misunderstood the way it works)

[Giuseppe De Marco]

You perfectly got it, TA and INT must provide the fetch endpoint; leaf not. Please note that the roles can be different in different federations, example: an intermediate in federation A is a leaf in federation b. Yes, the authority_hints is used to discover the superiors and the path to the trust anchor. the third column represent how the trust chain is composed; down, at position ZERO we have the leaf EC, then the superiors ES. The third column is a graphical representation of the trust chain. Do you suggest to have another column? The scope of the third column is representing the trust chain. The entity statement is then issued by a TA/INT for a specific subject (another INT or a Leaf). Probably you are looking for the TA’s EC in the figure 5, well: it is optional in the trust chain. I can understand why you propose a trasversal arrow instead of an orizontal one. Do you suggest ot inlude the TA’s EC in the figure 5?

[David W Chadwick]

Yes that was the idea of the self-signed entity statement

[David W Chadwick]

So in my opinion the trust chain comprises

1. The trust anchors self signed entity statement
2. The entity statement of the intermediary signed by the anchor
3. The entity statement of the leaf signed by the intermediary

‌

[Giuseppe De Marco]

Regarding the point 1, in the italian OIDC impl we have required the TA EC in the Trust Chain, because we have default constraints and trust mark issuers. There may be impl that doesn’t have these, then the TA EC in the trust chain would not give any benefit. While for points 2 and 3, ok, it’s already in the specs. I’ll do a check with the other authors if the reasons why the TA’s EC is not required in the TC are enough and for any other consideration in support of the cases where it is recommended. Thank you for this issue

[Giuseppe De Marco]

David in the current text we have this that it seems pretty clear to me

regarding the picture 5, WDYT about this?

‌

[Giuseppe De Marco]

Editable ASCII here)

[David W Chadwick]

This is much better thanks. The description is also good. Here are a few suggestions for minor improvements to the figure:

1. Move the Leaf role and Entity Configuration boxes up so that they are opposite the ‘sub and key binding’ in the final column. i.e. in the middle of the final two trust boxes
2. Move the Intermediate role and Entity Configuration boxes up so that they are adjacent to its Entity Statement in the final column. (Actually they will need to be one square below so that the Fetch Endpoint line can enter the top of the Entity Statement box without going through the other two boxes

‌

[Giuseppe De Marco]

@david I really need a drawing to fully understand your hints, I want to do that but If you can please draw something, It would be very helpful to me!

[David W Chadwick]

There is nothing wrong with the contents of your boxes. It is just their position and the arrows. I have sent you an email showing what I mean.

[Michael Jones]

Will be fixed by https://bitbucket.org/openid/connect/pull-requests/686

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/686