> scenarios where the status list token might be served in both encodings which > is probably more of an edge case
Because of the mere possibility of this edge case, draft-ietf-oauth-status-list says clients MUST send an Accept header (and implies they MUST check the Content-Type header). That’s the poor design choice. Whereas if there were “jwt_uri” and “cwt_uri” fields, a client simply uses the one it understands. And if a client understands both, it’s 1 extra line of code to use its 2nd preference if it’s 1st is absent. > The important part for the client is the `Content-Type` Header I disagree. The important part for a client is getting a format it understands. A client rejecting a response it can’t handle by looking at the Content-Type is slightly nicer than rejecting it moments later when it fails to parse the response body, but that barely makes a difference. And there is a fair chance that some status providers inadvertently serve statuslists as application/json or application/octet-stream or with no with no Content-Type. So there is a fair chance that clients are better off ignoring the Content-Type. Typos in 8.1: “Accept-Header” -> “Accept header”; “Accept Header” -> “Accept header" — James Manger On Monday, 16 June 2025 at 9:30 pm Christian Bormann <chris.bormann=40gmx...@dmarc.ietf.org> replied: 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 General On 10. Jun 2025, at 05:01, Manger, James <James.H.Manger=40team.telstra....@dmarc.ietf.org> 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
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
