Aaron Parecki

Encountered two blockers working on this:

1) In a simple example of an img tag inside an e-content tag, the parsers are using the img tag as an implied photo property. This seems wrong to me. Example This means XRay sees a post like this as a photo post, and would remove the img tag from the content, which is definitely not the right thing to do.

<div class="h-entry"><p class="e-content p-name">Hello World <img src="example.jpg"></p></div>

{
    "type": [
        "h-entry"
    ],
    "properties": {
        "name": [
            "Hello World http://example.com/example.jpg"
        ],
        "content": [
            {
                "html": "Hello World <img src=\"http://example.com/example.jpg\">",
                "value": "Hello World http://example.com/example.jpg"
            }
        ],
        "photo": [
            "http://example.com/example.jpg"
        ]
    }
}

2) At the point that XRay is sanitizing the HTML value, the Microformats parser has already converted the HTML to plaintext.

For example, XRay sees this object and runs the HTML sanitizer on the HTML value:

{
    "html": "Hello World <img src=\"http://example.com/example.jpg\">",
    "value": "Hello World http://example.com/example.jpg"
}

This means I can't remove the img tag from the plaintext value since it's already been parsed. I think my only solution for this is going to be to create my own plaintext value out of the sanitized HTML. Unfortunately, that is not a straightforward process, as demonstrated by this relatively long function that does this in the PHP parser. However that might be the technically better option anyway, since XRay can't be sure exactly what method was used to generate the plaintext value from the original HTML anyway.

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_endpoint link 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.