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

Wed Jan 15 13:09:54 UTC 2025

Hi,

I'm definitely up for a call like the one you proposed, Mike, in order to make sure that I proceed in the right direction.

Thank you,
Marcus

________________________________
From: Michael Jones <michael_b_jones at hotmail.com>
Sent: Tuesday, January 14, 2025 05:51
To: jheenan_authletefwd <joseph at authlete.com>; Giuseppe De Marco <demarcog83 at gmail.com>; Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Cc: Certification <Certification at oidf.org>
Subject: RE: [Openid-specs-ab] Proposed next set of Certification tests for OpenID Federation

Thanks for your observations, Joseph.

With respect to Automatic Registration being underspecified with respect to being able to create some of these tests, hopefully we can start creating those for which there is no ambiguity and work together improve the spec and/or test definitions to remove any ambiguities.

Yes, due to their size, Trust Chains will require using HTTP POST.

Here’s my evaluation of the value of each of the three modes:

  1.  Deployed Entity – These are the tests we already have.  These are useful to people running Federation production.
  2.  Entire Deployed Federation – These are easy to create from the prior set by adding the straightforward code to walk the graphs.  These are useful to Federation operators.
  3.  Test Entity joined to Test Federation – These will let us run protocol tests, including Automatic Registration tests, which we’d tentatively agreed would be the next goal.  This mode also lets us run all manner of negative tests, which are important for security.

We can also talk about whether it makes sense to add the fourth mode that you suggest, which is a testing node temporarily joined to a deployed federation.  There are good arguments for both 3 and 4.

Is the next step to have a call between Marcus, myself, and probably you, Joseph to talk about next steps?

                                                                Thanks all,

                                                                -- Mike

From: Giuseppe De Marco <demarcog83 at gmail.com>
Sent: Thursday, January 9, 2025 4:05 PM
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Cc: Joseph Heenan <joseph at authlete.com>; Certification <Certification at oidf.org>
Subject: Re: [Openid-specs-ab] Proposed next set of Certification tests for OpenID Federation

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<mailto: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<mailto: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<http://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<mailto: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<mailto: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/20250115/ee26a99f/attachment-0001.htm>