#social 2016-07-13

2016-07-13 UTC
#
aaronpk
I believe the "certification" is essentially the equivalent of our implementation reports
#
aaronpk
except verified somehow
#
aaronpk
doesn't actually mean salesforce is consuming paypal IDs for example
#
aaronpk
there's only marginal benefit to having a bunch of services implement roughly the same protocol if they don't actually consume each others' identities
#
tantek
indeed. watch how it won't stop them from calling it "federation" though
#
tantek
from 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.
#
tantek
like where are the two columns which basically say "provides" "consumes" so we can see which each does?
#
tantek
ah well, I suppose it was about time for another repeat of the OpenID hype cycle
#
aaronpk
no wonder you need a library to deal with openid connect, look at all the "underpinnings" http://openid.net/connect/
#
aaronpk
hm this is not a good sign: "If you are interested in participating in the interop activities, join the OpenID Connect Interop mailing list." https://groups.google.com/forum/?hl=en#!forum/openid-connect-interop ... last post: May 5, previously: Apr 27, Oct 19, Sep 20..
#
tantek
right, AFAIK OpenID Connect is a just the latest way of openwashing a bunch of proprietary identity providers
#
tantek
(where openwashing means the open standards equivalent of say https://en.wikipedia.org/wiki/Greenwashing )
#
aaronpk
I wonder what it would take to make IndieAuth be compatible with OpenID Connect, the way it's compatible with OAuth 2.0
#
aaronpk
there are a lot of similarities already
#
aaronpk
obvs, since they're both based on OAuth 2.0
#
tantek
yes, might be interesting to reduce differences until consuming IndieAuth "just works"
#
aaronpk
OpenID connect seems to dictate more about the token structure, whereas IndieAuth left it opaque the same way OAuth 2.0 does
#
aaronpk
OpenID Connect apparently does not require that user identifiers are email addresses
#
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."
#
aaronpk
which means "https://aaronparecki.com" is an acceptable OpenID Connect identifier
#
aaronpk
oh 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
it's really unfortunate that supporting webfinger without a server-side scripting language is almost impossible
#
aaronpk
there are actually full examples of using non-email URLs as identifiers in openid connect
#
pdurbin
aaronpk: you like having the "https://" in there instead of just "aaronparecki.com"?
#
aaronpk
in what?
#
aaronpk
as a user, I always type "aaronparecki.com"
#
pdurbin
in your OpenID Connect identifier
#
aaronpk
openid connect actually has an explicit normalization step that converts that to "https://aaronparecki.com"
#
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. "
#
pdurbin
ah
#
aaronpk
so 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.
#
aaronpk
the authentication section is basically the same between the two since they both follow OAuth 2.0 for that http://openid.net/specs/openid-connect-core-1_0.html#Authentication
#
aaronpk
it starts getting more complicated after that, since then it talks about the client inspecting the contents of the token that's issued
#
aaronpk
someone needs to write an "OpenID Connect Simplified" article like I did for OAuth 2
#
aaronpk
whoa just found the wiki page from the accessibility group https://www.w3.org/WAI/APA/wiki/Micropub
#
aaronpk
would have been nice to hear about that back in feburary when they first looked at it :/
#
aaronpk
also... from feb "Since they don't have any server side implementations yet - it is too early to worry about it."
#
aaronpk
not sure how they got that impression, since there were implementations listed IN THE SPEC https://www.w3.org/TR/2016/WD-micropub-20160128/#servers
tantek, tantek_, lukasros and shepazu joined the channel
#
aaronpk
new Micropub WD is published! https://www.w3.org/TR/micropub/
#
Loqi
aaronpk has 185 karma
Loqi, tantek, tantek_ and KevinMarks joined the channel
#
cwebber2
aaronpk: 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"
#
cwebber2
given that client_secret isn't meaningful for a mobile/desktop application
#
cwebber2
and that there's no signature mechanism like in oauth 1.0
#
cwebber2
and you might be throwing together any number of protocol-compatible clients
#
cwebber2
what's the point of the client id?
#
cwebber2
it also seems oauth 2.0 doesn't provide any "official" API for registering clients... is this correct?
#
cwebber2
https://tools.ietf.org/html/rfc7592 it looks like that's a separate document
#
cwebber2
it 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
#
cwebber2
does that seem right?
#
aaronpk
We use the client ID in IndieAuth to fetch application information to show it to the user during the auth request
#
aaronpk
since our client IDs are URLs, it provides a way to get that data
#
aaronpk
also you can "register" redirect URIs using the same mechanism which is the only part that provides security without the client secret
#
cwebber2
aaronpk: ok, gotcha
#
aaronpk
for installed apps, the client id can still be a web page about the app
#
cwebber2
aaronpk: ah, interesting idea
#
cwebber2
aaronpk: thanks for the clarity
#
cwebber2
aaronpk: thanks for writing https://aaronparecki.com/2012/07/29/2/oauth2-simplified btw, it's helpful
#
cwebber2
aaronpk: 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?
#
cwebber2
aaronpk: maybe that's more useful when you do have a client_secret?
#
aaronpk
the auth code was meant for use with a client secret
#
cwebber2
ah ok, yeah I was wondering that
#
aaronpk
passing back the access token immediately is what's known as "implicit grant"
#
aaronpk
which is fine for native apps
#
cwebber2
aaronpk: got it, but in the case where you have a web application as the client, you don't want them to give away the secret key in that step
#
cwebber2
makes sense
tantek joined the channel