Irenes (many)so we feel like we might want to go to the trouble of drafting an OAUTHDEVICE SASL method and proposing it to the IETF
OAUTHBEARER is very nice for what it is but the world is more than just the web
R@ireneista we were just having a conversation with someone about how all of the "not web" software stacks feel like they haven't been updated since 2005 or something
@r yes, agreed. we're trying to renew that stuff in general, as we have a need for it, because it feels like the web is the present but no longer the future, you know?
Erin 💽✨@ireneista @r I’ve stared a lot at the SASL/GSSAPI/HTTP-Auth/EAP quadrifectra and I keep staring at them because there’s a Grand Unified Theory of Authentication that feels like its trying to hide in there yet it refuses to fall out
The answer is probably that you exclude Kerberos because it is frankly a bit weird and unify everything around the EAP model with something like EAP Reauthentication to get the speed back but well. the one thing that’s hanging on is Kerberos.
RFC 5296: EAP Extensions for EAP Re-authentication Protocol (ERP)
The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting. [STANDARDS-TRACK]
@ireneista @r and also as far as I can tell EAP Reauthentication was specified in 2008 and never implemented.
@erincandescent @r hmmmm involving EAP in this is a very interesting choice. our tendency is to avoid it as complexity that is usually relevant only within a highly specific domain, but we would still like to understand it at some point....
@ireneista @r EAP feels complex but at it's core is relatively simple
And interestingly it avoids the issue everything else has where you pick which Auth mechanism to use before having any sort of user identity so it's impossible to do migrations
And interestingly it avoids the issue everything else has where you pick which Auth mechanism to use before having any sort of user identity so it's impossible to do migrations
@erincandescent @r hmmmm that's interesting
@erincandescent @r not having to know the user identity before auth seems like an important feature for OIDC-style flows
@ireneista @r it doesn't have to be the final identity, it can be just @domain for routing purposes
@erincandescent @r oh good
@ireneista @r but also for the recursive ones (TTLS, TEAP) you provide the (probably) full identity to the end server before so it can pick a mechanism that can actually work for the data stored about your user account