FOLKS I have a new favorite image recognition edge case sent to me by @Esquiring
I give you KITTEN or CARAMEL SWIRL ICE CREAM
I give you KITTEN or CARAMEL SWIRL ICE CREAM
WeChat ID
aaronpk_tv
Wednesday, January 3, 2018
| plane |
1 hr 35 min
|
| train |
23 min
|
| bus |
4 min
|
|
612.8 miles
|
plane |
|
9.1 miles
|
train |
|
0.9 miles
|
bus |
-
-
San Jose, California • Wed, January 3, 2018 7:10am -
Bus
0.91miDistance4:18DurationStartEnd
-
San Jose, California • Wed, January 3, 2018 8:28am
-
at TSA SecuritySan Jose, California • Wed, January 3, 2018 8:31am
-
-
This spec intentionally doesn't specify how users authenticate themselves to their server, it only deals with how third-party clients can authenticate users where their domain name is their identity.
The analogous version of this in RelMeAuth, with Google as an example, is such: as far as the RelMeAuth client is concerned, it sends the user over to Google, and expects Google to handle authenticating the user. This might involve entering their password, optionally followed by a 2fa mechanism like a Yubikey or TOTP code. That is all invisible to the site they're logging in to.
Similarly, IndieAuth clients do not know how users authenticate to their own server, the client just expects to send them off to the authorization endpoint and get back a response later that can be verified.
It is not a good idea for a spec to require any sort of authentication mechanism between the user and their own authorization server, which is something that the OAuth 2.0 spec has also made clear.
Now, the rest of this conversation is essentially continuing the naming debate of indieauth.com vs IndieAuth the spec vs other options we've considered.
I agree with many of @tantek's points, like
... should be it "just works" even if you only setup rel=me
However, that is describing RelMeAuth, not this spec. And as @Zegnat pointed out, even just adding rel=me isn't necessarily going to guarantee that you can sign in to an arbitrary site that supports RelMeAuth, since you need to add a rel=me link to a service that the site you're signing in to supports, which requires that site to register an OAuth application and deal with that service's API.
I'm in the middle of renaming indieauth.com, the goal is that the wiki will redirect users to indielogin.com to authenticate them using the existing mechanisms: RelMeAuth, email, PGP, and IndieAuth. Nowhere in that flow will users see the term "IndieAuth" unless they include a
rel=authorization_endpointlink on their website to an IndieAuth server of their choosing.I definitely agree that signing in to the wiki needs to be as simple as possible. That's the reason I added so many OAuth providers as well as alternate methods to indieauth.com (soon indielogin.com) in the first place. We've even had some people who want to sign in to the wiki but don't have a Twitter or GitHub account and don't want one, which is why I added things like email and PGP authentication options, which were not described by RelMeAuth.
This is all to say that it's not the goal of this spec to include RelMeAuth. This spec is intended to be just the URL-based extension to OAuth 2.0. If "IndieAuth" is not the right name for this spec, that's a different issue.
-
Martijn van der Vennicknames: Zegnat martijn -
at Gate 28San Jose, California • Wed, January 3, 2018 9:40am
-
Paul Frazee✌️
http://pfrazee.hashbase.io
•
Jan 3
That provides a practical solution to spam. You have to be in the recipient's network to reach them.
That sounds similar to Vouch, a Webmention extension https://indieweb.org/Vouch Would love your thoughts on that. -
San Jose (SJC) to Portland (PDX)toAlaska Flight 3348
-
Fruit and Cheese Plate
-
Plane
614.13miDistance95:12DurationStartEnd
-
Neat #AugmentedReality demo of the new Apple Park building. Pointing the iPad at the scale model on the table shows an animated overlay of what it looks like inside!
-
The Apple Park Visitor Center is pretty neat. I do wish it was two floors taller so it had a better view of the space ship tho
-
Train
9.11miDistance22:34DurationStartEnd
