ideas from discussion with Oliver and Martijn:

• //, and / provides a list of all URLs like a web directory
• well-known path
• additional URL inside the status_list claim
• URL provided by the Issuer metadata

I would be supportive. I believe ISO called this the all_bucket property.

I would also be supportive, this work is needed

Editors are supportive as well on this feature. Do you have any preferences on how this should be achieved and why?

@c2bo and I gave it some thoughts.

This is what group/pool/aggregation (best name tbd) file could look like:

{
   "status_lists" : [
      "https://example.com/statuslists/1",
      "https://example.com/statuslists/2",
      "https://example.com/statuslists/3"
   ]
}

There would be an equivalent in CBOR, depending on your Status List Token, the group/pool/aggregation must be in the same encoding.

Is it ok to keep the group/pool/aggregation unsigned? (we think so).

Most important question is how to find this file. After discussion the 4 variants mentioned above:

Option A: predefined "/status-lists" in the same path provides the group/pool/aggregation

• Status List Providers must use a predefined URL path structure
• requires a Referenced Token to find the group/pool/aggregation URL

Option B: well-known path

• well-known may be hard to configure for some, especially when using CDN?
• easier to find group/pool/aggregation, but only if Issuer = Status List Provider

Option C: additional URL inside the Referenced Token

• two URLs
• requires a Referenced Token to find the group/pool/aggregation URL

Option D: additional URL inside the Status List Token

• two URLs
• requires a Referenced Token to find the group/pool/aggregation URL
• seems a little better than C as the Referenced Token remains smaller

Option E: URL provided by the Issuer metadata

• easy to find the group/pool/aggregation URL
• issuance protocol specific (seems bad)
• this could be OpenID4VCI Issuer metadata and/or VICAL extension

Current proposal is to use both Option E to easily find the URL and Option A/D to have an protocol-agnostic way.

Paul and I discussed a bit more and will create a draft PR with option D+E for further discussions / feedback.

Editors Call: Agreement that D+E seem the best options

Bikeshedding:
Distribution as in CRL Distribution isn't quiet the same
URLAggregationList?