Hi James, Thank you for the feedback!
The important part for the client is the `Content-Type` Header, which signals the type in the response. The Accept Header is just a nice to have for scenarios where the status list token might be served in both encodings which is probably more of an edge case. To the best of my knowledge, Content-Type also works fine with caching etc and is supported nowadays by most CDNs. This topic had been discussed in previous IETFs (especially IETF 121 if I recall correctly) and the consensus has been to make Content-Type mandatory and not pull that signal (what type of status list token) out of the HTTP request. Alternatives discussed included pulling the format into the URI (suffix) and the claim directly if I recall correctly. We were also not sure about “only" Content-Type as a signal before those discussions, but following those discussions, I think expecting content-type in the response is a reasonable demand and clients should be able to deal with the payload according to the header. If Content-Type is missing, it can also be seen as a pretty clear signal that the client needs to probe the content (e.g., try CWT and JWT decoding). Best Regards, Christian > On 10. Jun 2025, at 05:01, Manger, James > <[email protected]> wrote: > > draft-ietf-oauth-status-list offers 2 formats or status list tokens: JWT > (JSON Web Token) and CWT (CBOR Web Token). But only provides 1 “uri” field. > That’s annoying; not developer-friendly; and unnecessary. > > I suggest defining 2 fields: “jwt_uri” and “cwt_uri”. At least one must be > present. > > > 1 URI can “work” theoretically, but only if all clients and all servers > always use the Accept HTTP request header to do content-negotiation. That > complicates all parties. It means you can’t just paste the URI into a > browser. You can’t use the simplest HTTP GET method that every programming > language offers. Caching … who knows. > Perhaps the worst part is that 1 URI will mostly work even for clients that > use a simple get(uri) method and don’t bother about the Accept header. The > URI in a JWT will return a JWT (the URI in a CWT will return a CWT). The > client will assume the result is what they expect. Then some issuers will > require content-negotiation; some clients will break; those clients will be > “at fault”, but issuer may need to hack their content-negotiation for > interoperability. Better to offer 2 explicit fields for 2 explicit formats. > > — > James Manger > > General > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
