> 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)
We can imho relax the part on the Accept header - that could also be a SHOULD/MAY, but it is a bit cleaner if the client always sends its preference which was the motivation for the current MUST. The important part is that clients implement the parsing based on Content-Type which is as far as I am aware pretty normal nowadays. > 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. I would disagree that it is better to ignore: An unexpected (or no) Content-Type value is a clear signal that something is going wrong on the provider side - that is a lot better than no signal/ignoring the value. In the case that the provider is implemented and working properly the client gets the correct signal and work with it accordingly. Generally speaking, the current design optimises for less content/payload in the token and moves some complexity to the provider and retrieval. From previous discussions, we would assume that for most ecosystems, a choice will be made for the used format on the ecosystem level and the current design optimizes for that while still providing a mechanism for discovery should that not be the case. It also allows for deployments where status providers are pre-registered and relevant status list tokens fetched in advance - there is a clear signal what kind of status list token to expect in the response. Best regards, Christian > On 17. Jun 2025, at 03:47, Manger, James > <James.H.Manger=40team.telstra....@dmarc.ietf.org> wrote: > > > 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 > <mailto: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
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
