On Tue, Jan 13, 2026 at 11:17 AM Nico Williams <nico@cryptonector.com> wrote:
> What do you think of
>
> https://datatracker.ietf.org/doc/id/draft-williams-http-bearer-extension.txt
>
> ?
>
> Yes, it's HTTP-specific, but somee of that might be useful here.
Did you have particular pieces in mind? (I assume Sec. 2 and the
auth-params registry?)
I haven't dug very deeply yet but I worry that the carryover might be
pretty limited. Halfway-remembered opinions follow below; tell me if
any of it is surprising to you, because I'd like to be wrong.
Lack of strong user-agent semantics aside (that whole "invisible
distributed state machine" REST thing sure is nice), the natural
extension points available to servers in HTTP 4xx don't exist in
SASL/OAUTHBEARER, because OAUTHBEARER hardcoded a subset of the
`WWW-Authenticate: Bearer` auth-params in the server failure message
instead of fully deferring to HTTP. (Then to add insult to injury, it
renamed "error" to "status". :( ) So I don't think we can make use of
your (or any) extensions without an update to RFC 7628.
OAUTHBEARER *does* defer to HTTP for the client initial response, but
`Authorization: Bearer` has no auth-params defined AFAIK, so that side
of the extensibility doesn't seem to help us. Additionally, I think we
want token sender constraints ASAP, which probably means petitioning
the Kitten WG for a SASL/OAUTHDPOP rather than assuming Bearer will
live forever.
Specific spec feedback:
9. Single Sign-On
This section is INFORMATIVE.
When engaging in an OIDC or SAML redirect flow, or an extended
401/407 flow as in this document, ultimately the user-agent, the
client, and/or the user will have to authenticate the user to an
issuer. How that is done initially (e.g., with passwords, smartcards
and PINs, etc.) is out of scope here, but for Single Sign-On (SSO)
one will want to distinguish between "initial authentication" and
non-initial authentication (i.e., _not_ passwords, smartcards, PINs,
etc.), much like Kerberos [KERBEROS] does. A user-agent could use
cookies, or a "token-granting token" (similar to a Kerbero ticket-
granting ticket, both sharing the same acronym of 'TGT') to
repeatedly authenticate to an issuer for a limited time after which
the user has to once again engage in "initial authentication".
How does this suggestion interact with offline_access and the existing
refresh token concept?
> Also, what do you think of a GSS-API mechanism that supports JWT for
> client auth?
I'm probably the wrong person to answer this... I am pretty skeptical
of GSSAPI myself, bordering on cynicism (but I understand you are
heavily invested in it :D).
--Jacob
