Choosing between multiple challenges

[martinthomson]

it is possible for the WWW-Authenticate header field to include multiple challenges ([RFC9110], Section 11.6.1). This allows the origin to indicate support for different token types, issuers, or to include multiple redemption contexts

How would a client decide between two challenges? There are a lot of considerations:

1. algorithm choice - this might be obvious, because the client has a preference or because they do not support an offered algorithm
2. origin scope - should a client prefer to offer tokens with broader or narrower scope (no origin, a set of origins, a narrower set of origins)
3. redemption context - should a client prefer challenges without this value? how does the client choose between two different opaque values?

It's possible that the right answer for some clients would be to prefer broad over narrow, with algorithm preference being secondary.

Finally, and somewhat critically, if the challenge varies, the client does not replay that challenge when it makes a new request. That means that the server needs to remember the challenges it issues, potentially globally, so choosing highly variable challenges means that the server needs to maintain a store for those challenges (or their hashes). I think that this is the point of Section 2.1.1, but that is not clear from how that is constructed.

[chris-wood]

My take is that the choice is one of policy, i.e., not something that the specification needs to be opinionated about. That said, we could add text which describes considerations for making one choice or another, which might be what you're trying to suggest.

As for the server piece, yes, the origin needs to remember or be able to reconstruct all possible challenges. This is in 2.1.1. I don't see how it's not clear, so could you please elaborate a bit?

[martinthomson]

Yes, all I was suggesting is that some guidance would be useful.

As for the server piece, I can't see anything in 2.1.1 that covers the need to be able to reconstruct/remember the redemption context. For instance, it says:

This value can be a unique per-request nonce, constructed from 32 freshly generated random bytes.

But it doesn't say that the server needs to be able to recover this value from a hash.