[Openid-specs-ab] Proposed next set of Certification tests for OpenID Federation

Fri Jan 10 00:05:26 UTC 2025

Hey J

Thank you for you feedback, very valuable. I will get back on your points
with more attention asap, here my not yet comprensive answers

trust chains have expiration, an AS only Need to have a fresh (not expired)
trust chain about the client. If the client provides a fresh trust chain
within the request, it can be validated by having the trust anchor public
keys. If It is more fresh than the one already cached by the AS, the AS
should update its cache.

These are impl considerations that would merit their space within the specs.

The AS should benefit to only cache the valid trust chains. Smart
implementations also cache the processed metadata, to not process policies
again and again using the the same data.

Trust chains bring huge payloads, when used within the request, http post
method or uri or par are the only possible way to not get risks of request
URL params truncation.

Afaik, the test on the italian federation was made on the production nodes.
You can use and italian RP, requesting to it an authentication to the
italian openid CIE server, then inspect the CIE openid resolve endpoint to
evaluate how and when the AS has collected and evaluated the trust chain
about that RP. The resolve endpoint brings the transparency we need when we
deal with automatic registrations.

In this way, you can test a federation on production without implementing
RP or Op, you only need to statically evaluate the resolved response about
its issuers about a specific subject. One shot, two birds.

In Italy the resolve endpoint is therefore required, we realized that we
would not live without It.

Please don't forget that the current italian impl in production is about
draft 24, and that in Italy we don't want to handle changes until the specs
Will be an official standard.

Differently, for the wallet ecosystem we are handling periodical alignments.

We still have come road to do together before finishing all this, I really
appreciate the good company.

Thank you all

Il gio 9 gen 2025, 22:28 Joseph Heenan via Openid-specs-ab <
openid-specs-ab at lists.openid.net> ha scritto:

> Hi all
>
> Just to put some some of the items I mentioned during today’s working
> group call into writing; after a quick (and not comprehensive) review a few
> worries spring to mind:
>
> I’m not convinced that Automatic registration is clearly enough defined in
> the specification to do some of these tests - e.g. I think there’s a lack
> of clarity over what servers might or might not be permitted to cache
> during the automatic registration, e.g. I wouldn’t expect an AS to
> re-verify the trust chain on every authorization endpoint call but I think
> there’s one test that expects that passing an invalid trust chain would
> reliably result in an error. I’m also not sure if the server allowed to
> skip some other validation steps if the client was already registered.
>
> I think the flexibility in the spec over how to deal with the request
> object (if it includes the trust_chain) potentially being larger than
> actually works in practice is not helpful for interoperability tests (e.g.
> as well as permitting a normal redirect to the authorization endpoint, it
> allows a POST, or the use of request_uri, or PAR).
>
> On the 3 different deployment modes, we should make sure we’re clear which
> of the 3 modes we want to focus on testing initially - I’d suggest
> focussing on what we think we deliver the most value.
>
> And something I’ve further reflected on since the working group call - I’m
> not sure that “Entity Joined to Test Federation” mode is actually necessary
> for some of the positive/negative tests. I suspect there’s an in-between
> position where the conformance suite is temporarily made a leaf (not sure
> if that’s the correct word) in the production federation that the entity
> under test is a part of. This is how we approach, e.g., OpenBanking testing
> that allows us to test a production bank. My gut feeling is that it’s
> probably important we’re able to do that kind of production testing against
> a production node in a real federation too, if we’re going to make sure
> that things actually work in that federation in production - e.g. in seems
> important to test client registration in that kind of way. I don’t know if
> there’s any Federation specific issues that might stop that working.
>
> Thanks
>
> Joseph
>
>
>
>
> On 1 Jan 2025, at 06:49, Michael Jones via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
> As a result of discussions with the Certification team and the Connect
> working group, we decided that the next steps for certifying OpenID
> Federation deployments and implementations would be to add tests exchanging
> protocol messages between the implementation being tested and federation
> conformance testing software at www.certification.openid.net.  The
> attached spreadsheet defines an initial set of such tests, both using
> Automatic Registration and Explicit Registration.  It also includes the
> previous set of tests, updated per feedback from Marcus Almgren, who
> implemented them.
>
> As described in the (short) attached Word doc, we plan for there to be
> three modes of tests available for Federations:
>
>    - *Deployed Single Entity Testing: * Tests the properties of an Entity
>    deployed in a Federation in detail.  Obviously, only features used by the
>    Entity can be tested.  All the tests we have now use this mode.
>    - *Deployed Entire Federation Testing:*  Tests the properties of an
>    entire deployed Federation graph.  Obviously only limited information can
>    be logged so that the log sizes for Federations with thousands of Entities
>    do not become unwieldy. We expect this mode to be useful to Federation
>    Operators for identifying problems in their federations.
>    - *Entity Joined to Test Federation:*  Tests the behavior an Entity
>    within a custom federation created for certification testing purposes.
>    Both positive and negative tests can be run in this manner, as are tests
>    over a broader range of inputs controlled by the certification suite.
>
>
> The new “*Test Modes*” column in the spreadsheet indicates which
> combinations of the three modes tests are applicable for:  Deployed (1),
> Entire Fed (2), Test Fed. (3), or All.
>
> These tests are informed by the tests developed by the Italian SPID CIE
> team and also by discussions with those involved in the Italian and
> multiple other European deployments, Australian deployments, the Connect
> working group, and the Certification team.  Please let us know what you’d
> like to see us do next!
>
>                                                                 Happy New
> Year!
>                                                                 -- Mike
>
> <OpenID Federation Conformance Features 31-Dec-24.xlsx><Certification
> Testing for OpenID Federation 29-Dec-24.docx>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250110/ca3e7be5/attachment-0001.htm>