On Jun 17, 2014, at 11:28 AM, Stephen J. Turnbull wrote:
Were we (on dmarc@ietf) talking all along about OpenID when we wrote "OAuth"? They're different, although I don't know exactly how or why (and neither RFC made obvious mention of the other :-( ).
I haven't been keeping up with the latest OpenID and OAuth specs, but one way I think about it is that OAuth is a web-service delegation protocol, while OpenID is more of a single-sign-on protocol.
Let's say you have a web service, like, oh I don't know, Mailman 3's REST API. You want to script some interactions with this service, perhaps locally, or you want to allow some other application to do it on your behalf. Normally, you'd have to hard code your username and password in some local file, or enter it into the third party app. With OAuth, you can acquire a token from the service which is used to sign requests, so that the service knows it's coming from you. Thus you can hand the third party application your token without giving it your password, and most services provide you a way to revoke tokens if you e.g. stop using the third party app. Usually, you round-trip through a web browser (the only "trusted agent" on your system) to acquire the token, but there can be other ways.
OpenID is more like a single-sign-on technology. Let's say you want to log into Bitbucket for the first time, but you don't want to have to register yet another username and password with yet another web site. Fortunately, you have a Launchpad account, which is an OpenID provider, so on Bitbucket's login page you enter your OpenID, which is an https url pointing to your Launchpad page. After some dancing with Launchpad and Ubuntu's SSO, Bitbucket logs you in. The point is that Bitbucket doesn't have access to your Launchpad password - it delegates authentication to Ubuntu's SSO and Launchpad, which as it turns out can also be made to require two-factor auth for additional security.
Thinking about it this way, I'm not really sure what's being considered for DMARC, although either make some sense in different contexts. My guess is that it's probably OAuth based; I'd get a token to submit messages via a web service using authenticated and signed requests. But that's just a guess.
-Barry