[fluffy]like my private blog posts are still at https://beesbuzz.biz/blog/ as the feed - no separate feed for private posts or whatever. I feel like people are expecting the indicated resource to specifically be the restricted content. Is the expectation that any post will generate a ticket sent to all trusted subscribers? Because that feels an awful lot like how ActivityPub privacy works, and it’s not great for a lot of reasons.
[fluffy]IMO the protocol should be like… `resource`/`realm` to point to where access is being granted, and `issuer` as an *optional* property indicating where the endpoint is declared. Or even declare the endpoint directly as `cb` or something.
[fluffy]and my intended flow was that if someone was to sign in via Authl then that’d trigger a ticket grant automatically, if they have a ticket endpoint. (And there’d also be a provision for folks to request a ticket grant.)
[fluffy]Okay, and that’s what my previous assumption was. But some of the commentary on the wiki page makes it sound like people want the tickets to be to a specific resource, i.e. just one page.
aaronpkso the resource indicator spec specificallly talks about the example you're talking about, where the resource could be the top-level page on the domain
aaronpkor more concretely, if my home page was not a feed, and i have several feeds like /articles/notes, i could use multiple resource URIs to describe the multiple feeds without giving it access to the whole domain
[fluffy]My home page is not a feed but it declares an atom feed. I also think I purposefully don’t have h-feed markup on my site yet (although I do plan on adding that someday)
[fluffy]I guess that’s what I mean by ‘independent of indieauth’ - there’s no need for the authorization_endpoint on the part of the person getting the token
aaronpksure, but then in practice you'll end up with something that acts basically like the authorization endpoint in the end by the time you build out the actual complete system. it just might not be described by the spec
[fluffy]like I could see some random non-indieweb feed reader like feedly or Feed-On-Feeds providing a ticket endpoint without having the rest of the indieauth thing
[fluffy]SelfAuth doesn’t provide a token grant mechanism AFAIK (and if it does I don’t use it) and Publ doesn’t make use of token grants either; it only cares about the authentication flow, rather than authorization.
[fluffy]and I mean given that the token grant is so similar it does seem like the default should be to make them part of the same spec, and just let it undergo mitosis later if necessary
aaronpkWith another spec group im involved with, it started out all as one spec with one repo, and when it made sense, we split out a chunk into its own spec and made a new repo and moved all the issues over
GWGI was making the case to move the resource and expiration discussion into the main IndieAuth spec as that's token endpoint, not ticket endpoint business
GWGIt is a specification that allows the receipt of tickets, or invitations to share private stuff, and redeem that invitation at an OAuth2 token endpoint with an new grant_type.
[fluffy]but even then Publ itself is only an IndieAuth client, not a provider. Or rather it uses Authl which is only a client for a lot of things. It actually provides a few different OAuth client roles (indieauth, mastodon, and twitter for now, and I plan on eventually adding facebook and tumblr when I get around to it)
batkin[m]Yeah, the demo worked well, except one glitch i haven't figured out how to reproduce, which is either on datasette-indieauth or wordpress indieauth
aaronpkSince IndieAuth is an extension of OAuth, it technically doesn't need to reproduce every aspect of OAuth like expires_in and refresh tokens in the spec. There's nothing about refresh tokens or expiring tokens unique to IndieAuth
[tantek]sknebel, capjamesg, last time I tried, <li><p> or <li><blockquote> would autoclose the <li> before the subsequent opening tag. fairly certain this is still the case though I suppose we could create small example and check the DOM in dev tools
[fluffy] like my private blog posts are still at https://beesbuzz.biz/blog/ as the feed - no separate feed for private posts or whatever. I feel like people are expecting the indicated resource to specifically be the restricted content. Is the expectation that any post will generate a ticket sent to all trusted subscribers? Because that feels an awful lot like how ActivityPub privacy works, and it’s not great for a lot of reasons.
aaronpk i made a label to find them: https://github.com/indieweb/indieauth/labels/ticket-auth
batkin[m] I was curious if indieauth had a CVE, and it looks like we're popular enough! BTW my prototype has the same problem. #laziness https://github.com/advisories/GHSA-mjcr-rqjg-rhg3
petermolnar capjamesg: I use a definition list.
GWG https://indieweb.org/2021/Pop-ups/Microsub - If people would like to add possible topics