#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 http://openid.net/specs/openid-connect-discovery-1_0.html#IdentifierNormalization
#
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 so the webfinger request to find my openid connect authority would be https://aaronparecki.com/.well-known/webfinger?resource=https://aaronparecki.com&issuer=http://openid.net/specs/connect/1.0/issuer
#
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 http://openid.net/specs/openid-connect-discovery-1_0.html#NormalizationSteps
#
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 https://www.w3.org/WAI/APA/track/actions/2014
#
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/
#
ben_thatmustbeme aaronpk++
#
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