nolith!tell [grantcodes] how can I debug "my posts" section on together? I can see the `q=source` message in my logs, but the list in the app is empty :(
nolithaaronpk: if I prepare a PR for https://github.com/aaronpk/indielogin.com supporting GitLab.com logins, will it be available for websites using indieauth.com as authorization_endpoint?
Zegnatnolith: indielogin.com is not an indieauth authorization_endpoint, it is a service that other websites can rely on the handle login for them (outsourcing all those oauth buttons). So if you were to add a PR for GitLab logins there, it means sites that use indielogin.com (like indieweb.org) will then allow GitLab logins
nolithI'm using indieauth.com on my blog. I'd like to be able to login using GitLab.com credentials when I put my website quill (or other micropub clients). Where should I contribute the missing implementation Zegnat ?
ZegnatYeah... blame that one on naming being hard. IndieAuth.com can do two things: function as a login handler for apps *and* function as a authorization endpoint for users. The first part is being replaced with indielogin.com (as it already has been on indieweb.org), the second part does not have a replacement yet
ZegnatSee the https://indieauth.com/ homepage. It has a red Deprecation Notice and slightly more feedback about the issue right below it (where it is split between For Developers and For Users)
ZegnatNot to say that a PR for GitLab for indielogin.com would not be appreciated! It will allow you to rel=me link to gitlab on your site and be able to login to the indieweb wiki with just that. Just trying to make clear that we are talking about two different things :)
[grantcodes]nolith: Not too sure for debugging `q=source` query in together to be honest. You can open up the console and see responses from the graphql server and I think it should log errors there
jeremycherfasI'm just astonished by what Datasette has allowed me to look at, using only my Healthkit export. And fun, too. I suppose I better write up this mini-adventure.
nolith[grantcodes]: thanks. I got https://pastebin.com/wkDc0L8M It looks like my item names are a string array but together expects a string. The funny thing is that I'm not writing the json myself, but it's what the ruby microformats gem extracts from my pages. In any case I need to figure out why my pages have 2 `name` values
nolithMy site it's quite a Frankenstein, it's a static generated site, plus a micropub server hosted elsewhere that commits changes with GitLab APIs and then CI deploys the website. I've also implemented webmention.io webhooks to recompile with webmention
stevestrezayou can change the expiration date on an expired key, though it might require subkeys that are only in your airgapped setup depending on how you set it up
ZegnatBut that is the one way the client can allow itself to skip the rediscovery. If it already knows what it is going to find from previous discovery
ZegnatI wonder if this, rather than being a security considerations section, should not just be the last section of the spec. The last step of the flow that clients should always do when they have received a `me` value ...
ZegnatI am thinking, the `me` returned from the AS is trusted from the user/AS point of view, but is not yet trusted from the client point of view as the user might be trying an impersonation attack. So the client should try to establish a trusted relationship between `me` and `authorization_endpoint` no matter what.
Zegnat"Hi aaronpk, just checking in with you to [confirm|verify] that sknebel is acting on your behalf." ...... I guess confirm does sound better to me in that sentence
ZegnatBut that again makes it sound like it is confirming the auth endpoint, not the me given by the auth endpoint. Surprisingly tricky wordsmithing here, hahaha
ZegnatThen I would say, sknebel, lets keep the change in the "MAY" line in mind for when aaronpk comes in with the rearrangement of that section. And get the PR merged as it is, if nothing else big stands out.
ZegnatKeep thinking the one that does not redo discovery is optional, because if you want to be sure you can always redo discovery and that will give the correct answer.
ZegnatWe do not really seem to use it anywhere except for the standard intros/appends texts. So, like I said, meh. Examples seem clear to me and cover those we have previously discussed. So that seems good to me.
ZegnatStill find myself wishing for a better phrasing than "either of the following", but that might also me being a non native speaker throwing a wrench
ZegnatOh. Maybe I also find it jarring because I expect statements that can be true/false following such a phrasing. But instead the list seems to have actions? (E.g. they start with a verb.)
aaronpkbut doesn't "checking that either of the following is true" imply that if you can check the second one is true then you don't need to check the first?
ZegnatI can see that. It is a bit tricky. The only reason it can be bypassed, is that the exact step has already been done during initial discovery in one very specific case. So it can be optimised away.
aaronpkok so actually the "MUST" is "It MUST verify that the canonical profile URL declares the same `authorization_endpoint` as the initially-discovered authorization endpoint"
sknebel" the client MUST verify the authorization server is authorized to make claims about the profile URL returned (i.e. the profile URL leads to a URL declaring the same authorization server).
Zegnataaronpk: yes, the MUST is to verify that. And there are basically 2 ways: 1/ the client already knows it has the same authorization_endpoint because the canonical profile URL was visited during initial discovery, or 2/ the client redoes discovery on the canonical profile URL
sknebelmaybe just an extra sentence a la "note that if the first is true, the second is also, so implementations MAY only implement the second check (at the cost of extra requests)
ZegnatA valid client could implement just B, not A, without issue. But if you want to avoid the extra HTTP call, the client may want to implement A on top of B.
aaronpkso, it is actually accurate to say that a client MUST do that step B. maybe then we add a note below that saying here is one way to optimize your code
ZegnatYep. Step A is purely an optimisation. But I felt like it would be good to let implementers know that it is very much a valid / safe optimisation. In general I would advise against people coming up with optimisations in auth code otherwise
sknebel" the client MUST verify the authorization server is authorized to make claims about the profile URL returned (i.e. the profile URL leads to a URL declaring the same authorization server). "
aaronpk"the client MUST verify the authorization server is authorized to make claims about the profile URL returned by confirming the returned profile URL declares the same authorization server"
ZegnatPart of the requirement is that "the returned profile URL declares the same authorization server" in accordance with discovery's rules? I feel like it needs to link back to that somehow
sknebel"any of the URLs encountered during the <a href="#discovery-by-clients">initial endpoint discovery</a> either from a possible redirect chain or as the final value.</p>" <- does that need a "," after the </a>?