#aaronpkdoesn't actually mean salesforce is consuming paypal IDs for example
#aaronpkthere's only marginal benefit to having a bunch of services implement roughly the same protocol if they don't actually consume each others' identities
#tantekindeed. watch how it won't stop them from calling it "federation" though
#tantekfrom looking at that list they look like all providers, which is likely the only thing certification is testing. the various columns are cryptic and unclear what they mean.
#tanteklike where are the two columns which basically say "provides" "consumes" so we can see which each does?
#tantekah well, I suppose it was about time for another repeat of the OpenID hype cycle
#aaronpk"The user input Identifier SHOULD be a URL or URI relative reference defined in RFC 3986 [RFC3986]. The user input Identifier MUST include the authority component."
#aaronpkwhich means "https://aaronparecki.com" is an acceptable OpenID Connect identifier
#aaronpkoh wow a plain hostname like "aaronparecki.com" is allowed too
#aaronpk"Examples are example.com, joe@example.com, example.com/joe, and example.com:8080"
#aaronpk"For all other inputs without a scheme component, the https scheme is assumed, and the normalized URI is formed by prefixing https:// to the string as the scheme. "
#aaronpkso the discovery aspect of OpenID Connect and IndieAuth are totally different. IndieAuth in this case supports discovery on identifiers that happen to be HTML documents whereas OpenID Connect has the limitations of webfinger.
Loqi, tantek, tantek_ and KevinMarks joined the channel
#cwebber2aaronpk: so I'm trying to think about if the client_id can be in any way meaningful in OAuth 2.0 in the situation where you're running a server for say, a few friends, and any one of them might script together their own "client application"
#cwebber2given that client_secret isn't meaningful for a mobile/desktop application
#cwebber2and that there's no signature mechanism like in oauth 1.0
#cwebber2and you might be throwing together any number of protocol-compatible clients
#cwebber2it seems like the oauth 2.0 parts that matter really then for the desktop/client application space of a personally run server is the way of obtaining a bearer access token, and the way that you officially provide it with every relevant request
#cwebber2aaronpk: I guess the one thing I also still don't get is, what's the point of the intermediate auth code? why not pass back the access token immediately?
#cwebber2aaronpk: maybe that's more useful when you do have a client_secret?
#aaronpkthe auth code was meant for use with a client secret