[Openid-specs-ab] OpenID Connect Federation draft 09 ready for your review - part3
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
I see 2 cases:
1) Combining the different policies fails
2) Applying the combined policy to the entity metadata results in
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 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
Right, that sentence should be removed.
Otium cum dignitate - latin proverb
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab