[Openid-specs-ab] OpenID Connect Federation draft 09 ready for your review - part3

Roland Hedberg roland at catalogix.se
Sat Nov 2 16:57:40 UTC 2019

> On 29 Oct 2019, at 16:43, Marcos Sanz via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> - Section 4.1: It's not clear to me what should happen if application of 
> the policy language results (or would result) in incorrect entity 
> metadata. While 4.1.2 and 4.1.3 state "applying the policy MUST lead to 
> failure" (this suggests process interruption and thus, probably, that the 
> policy being processed wouldn't change the metadata of the whole entity 
> under application), 4.4 says that in case of some claims having all their 
> values removed (a subset of the possible reasons for an incorrect end 
> state) only the responsible metadata statement will be removed. I think 
> that a clear/coherent statement for failure processing is needed for all 
> elements of the policy language if we expect this to be implemented 
> consistently.

I see 2 cases:
1) Combining the different policies fails 
2) Applying the combined policy to the entity metadata results in
incorrect  metadata.

Both cases must lead to the metadata being rejected.

> - Section 7.1: It says "Once the Consumer has found a trust anchor it 
> wants to use, it MUST complete the trust chain by fetching the trust 
> anchor's self-signed entity statement" This sentence is in contradiction 
> with other parts of the spec: Section 2.2 clearly states that the trust 
> chain "ends with an entity statement issued by the trust anchor about the 
> top-most intermediate [...] or the leaf entity [...]", and it does thus 
> exclude from the chain the (certainly most probably existing) trust 
> anchor's self-signed entity statement. Verification algorithm of 2.2 
> ignores the TA self-singed ES, so does Appendix A.1.7.

Correct ! Missed that during the last rewrite.

> - Section 7.2: It says "using the rules laid out in that [Section 2.2] 
> section" and it's not clear to me now what section is authoritative for 
> such an important thing as the trust chain validation algorithm. In any 
> case, duplication is definitely the worst option: A proof of that is that 
> the pseudo-code in 7.2 does not match completely what 2.2 says, even after 
> the aforementioned ammendment about ES[0] verfication. That's described in 
> next point.
> - Section 7.2: The chain validation algorithm in 7.2 is broken. It looks 
> like it considers the TA self-signed statement to be part of the chain (cf 
> "for j=0,i verify that iss==sub"), but if that's the case, you'll easily 
> see by setting i=1 (no intermediaries, just one leaf and a TA) that you 
> only perform 2 signature verifications instead of the 3 that'd be needed 
> (self-signed leaf ES, TA about leaf ES, self-signed TA ES).

It’s an error.

> - Section 8.1: It says "If a leaf entity uses jwks_uri...", but I don't 
> see how jwks_uri would be honored at all in this spec, so I think the 
> statement about key rotation is void.


> - Section 8.2: "A trust anchor must publish a self-signed entity statement 
> about itself. As described above in Section 2.2, it should be at the end 
> of the trust chain". Section 2.2 says actually the opposite, see further 
> up.

Right, that sentence should be removed.

- Roland

Otium cum dignitate - latin proverb

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20191102/f1ac1a04/attachment.html>

More information about the Openid-specs-ab mailing list