Seb[d]Ticket Auth is trying to have some kind of token exchange so that I know your feed reader is you, so I can give it private posts I want to share with you.
ZegnatSo instead of the reader knowing a feed is private and going out to request access, the publisher send the reader an invite (a ticket) that will get them access (an OAuth token) to a private feed.
[fluffy]Yeah Publ supports it fully, in theory, although there's still no readers that do the crucial last bit of “send the granted bearer token with the request”
[fluffy]Publ’s security model is that it just sends a ticket grant to anyone who signs in by IndieAuth (because the token is granted to a user, not to a resource) so it should be pretty seamless… someday
ZegnatI know OAuth thinks about tokens differently, and then there is the resource scoping and all that, which is nice to have support for. But I think for most IndieWeb usecases token = proof of identity is better conceptually
[fluffy]Theoretically TicketAuth isn't even tied to IndieAuth although it's very difficult to imagine a world in which that is anything other than theoretical
[fluffy]But like one could build an RSS reader that has a TicketAuth endpoint and then, say, Twitter starts to let people add arbitrary endpoints to their user profile
ZegnatTrue. TickAuth can probably (and maybe should?) stand on its own as an OAuth extension, just like IndieAuth does. But I think there can be a difference in the technical truth of the spec and how the possible features are presented :)
ZegnatI think there is some gain in being able to say that TicketAuth is a new grant type for OAuth flows. But yeah, you do not need a full OAuth compatible setup to offer redeem tickets
[fluffy]And right now TicketAuth is the only thing Publ supports in its token endpoint. Eventually I need to make that accept plugins for things like micropub or whatever though. Lots of circle-squaring needs to happen.
[fluffy]I made a very simple page submission system for novembeat.com which exposed a lot of issues in how I was assuming that content updates work, and I'm now thinking the file watchdog is kind of a mistake. Or at least shouldn't run in production, and that production sites should be explicitly reindexed.
ZegnatIndieAuth is syncing up with the OAuth Server Metadata spec. Which enables an IndieAuth capable service to declare all its different capabilities and endpoint URLs in a single metadata file, which hopefully makes things easier on clients.
[fluffy]But as long as traditional discovery remains a requirement I won't have to fix Authl (which, as a client, only cares about authorization_endpoint).
[fluffy]I guess I should look into this spec change. What’s the tl;dr on it? Am I going to have to replace my simple flow of ‘fetch the page and then know the endpoint’ with ‘fetch the page and then fetch another resource to know the endpoint’?
GWG[fluffy]: Yes, the flow will be, fetch the page, fetch another resource to know the endpoint. If the page doesn't have the new endpoint, fall back on the old endpoint.
[fluffy]I guess my big question is what does it save or make easier? like, the existing spec is already straightforward to implement, and the cost of adding an additional HTTP header or <link> element is trivial and involves less overhead than issuing an entire additional HTTP transaction.
ZegnatIt is mostly that. Instead of having people put up <link> elements for discovery of authorization endpoint, token endpoint, ticket endpoint, introspection endpoint, it will just be a single <link> element for the metadata.
ZegnatAlso means that users of an external service like a future indieauth.com-like thing only need to have the one link, and the service can continuously evolve its capabilities
GWGIndieAuth metadata adopts OAuth 2.0 Authorization Server Metadata [[RFC8414]], with the notable difference that discovery of the URL happens via the IndieAuth link relation rather than the <code>.well-known discovery</code> method specified by RFC8414. For compatibility with other OAuth 2.0 implementations, use of the <code>.well-known</code> path as defined in RFC8414 is RECOMMENDED but
[fluffy]so now there’s three potential mechanisms for discovering the endpoints, of which one is required, one is deprecated but still needs to be supported, and one is optional? that’s gonna be a mess.
[fluffy]yeah. I suppose I can wait on even adding the metadata change until someone opens a ticket against authl because they tried to sign in with metadata-only and couldn’t.
ZegnatI am not even sure how that .well-known is supposed to help jamietanna. Because I can only find that if I already know your auth server is hosted on indieauth.jvt.me surely? Or do you have the same .well-known for www.jvt.me?
ZegnatIt could be interesting if aaronpk could see from indielogin how much is PKCE-less. As I guess the majority of IndieAuth traffic goes through there for indieweb.org
ZegnatIt is not actually a problem, because HTTP itself obviously allows underscores in headers. And it looks like nobody bothers to validate Link headers specifically.
GWGI just adjusted Ticket auth to note that the ticket endpoint should be discovered in Indieauth metadata, noting the previous option as deprecated. Being as Ticket Auth is still early days, I don't think we have to keep compatibility.
[fluffy]I’m somewhat surprised that underscores aren’t allowed in link headers but I guess it’s nice that the spec takes a stand. I generally prefer dashes to underscores anyway and I really dislike how many programmers default to underscores for everything, for reasons which usually boil down to “that’s what my compiler makes me name variables with”
[fluffy]every now and then I come across a hostname with an underscore in it and I’m like… how is that working and how was this problem not caught at any of the myriad steps which were involved in setting this hostname up
[fluffy]and then somehow it mostly works until it doesn’t, and then people think the problem is on my end that whatever random thing isn’t able to support a spec-violating hostname
Zegnat> Links are a conceptual construct, created by a, area, form, and link elements, that represent a connection between two resources, one of which is the current Document.
[fluffy]yeah i was just perusing that, didn’t find that specific section but the description of rel is just that it’s case-insensitive and space-delimited
[fluffy]and I don’t see any mention of dashes or underscores, but I do note that all of their listed known rel types (which is non-normative/non-exhaustive) all use dashes.
ZegnatHonestly it is fine that HTML is not following HTTP specs. But for our usecase where we want it to be i both places that makes it a little more restricted
ZegnatAnd even then only if you really want to conform to the HTTP Link spec, which the last years have shown we do not need to do to have it work. But conformance is nice to have anyway
[fluffy]I mean, it seems to me like the whole point to HTTP Link is to support <link> on things that aren’t HTML, so shouldn’t they have rel-equivalence?
[schmarty]GWG: i find that issue very hard to understand. (the description literally just references two other things by number: "as proposed in #82 to address #83"
ZegnatI still find resource and/or realm scoping tough to discuss, and that is after reading up on it a lot. It does not help that I am not sure we have ever seen a real world need for them yet in our implementations
ZegnatBut I am still not sure if there was a direct need, other than wanting to scope scopes to the correct endpoints, which with the scopes we are currently used to may not even be needed yet.
[schmarty]aaronpk++ 1000% agree that Resource Indicators needs some real-world experimentation and spec-ing out as an extension before it becomes part of the spec
Loqi[martymcguire] I have a few questions about how this would be used:
1. The language so far in #96 covers how an IndieAuth client can include `resource`s in an authorization request, but doesn't mention any mechanism for discovery of resources. Some examples:
...
GWGTo quote 2020 aaronpk : So the idea with resource indicators is it's a way for the client to tell the authorization server, "I only need an access token to go and talk to this particular resource server, and I'm never going to bother sending it to any of these other ones."
GWGFor me, if you only request scope, I'd probably issue scope, and then restrict the token by default to the resource that scope reflects, if I only have one resource using it.
ZegnatHmm, I guess that is some sort of usage narrowing then. A token without scopes does not grant you any priveledges. So it to me maps to an identity token. If the token does nothing other than showing your identity to me, I am not sure I will ever care on which URL you are telling me your identity. So I guess I wouldn’t immediately think to get a resource associated with it.
ZegnatBut there is some sort of security there, I guess, if you have a token that can only identify who you are to 1 place it cannot be stolen and used against other URLs.
GWGPrivate posts have been an issue because we've tried to solve all aspects at once. This would address the issuance of a token to read private posts... with the getting of said token being a separate issue
[schmarty]I still think `resource` adds more confusion than it alleviates in most cases. It creates a lot of options that are currently implementation details. If a Micropub endpoint implementor and a Micropub client implementor make different choices they can become incompatible
[schmarty]Like in jamietanna's case where his Micropub endpoint requires both scope and resource to match - a Micropub client won't work for his site unless it knows to ask for that resource
[schmarty]To be backwards compatible his auth/token server could add that resource as a default for compatibility, but that's an _internal_ detail and doesn't require `resource` as part of the spec at all
[schmarty]So while `resource` is proposed as being optional in the spec, its existence creates muddy situations without a lot of guidance about when and why you'd use it and when you _would not_ want to use it
[schmarty]The TokenAuth case you laid out makes some sense, but you don't need `resource` to be part of the spec for my resource server to offer your whatever endpoint a token that only has access to specific feeds or whatever
GWGIf we decide not to adopt resource as a parameter, we can amend the spec to note that if resource indicators are used by a server, they can be used in lieu or in addition to a scope
aaronpkthe key feature resource indicators adds is the ability for the client to tell the indieauth server where it plans on using the token. if that's not a useful property, then we don't need it
aaronpkas [schmarty] described, the AS and RS can already do their own internal logic for limiting capabilities of tokens. this lets the client become part of that negotiation
[schmarty]Looking forward to seeing some working interoperable implementations of this in an experimental fashion, leading up to maybe an extension to the spec 😅
aaronpkwe are already effectively using "scope" as a resource indicator since we have a list of scopes that are agreed upon between clients and servers
Seb[d]Hmm, the IndieAuth specs says: "Additionally, host names MUST be domain names or a loopback interface and MUST NOT be IPv4 or IPv6 addresses except for IPv4 127.0.0.1 or IPv6 [::1]."
ZegnatIs there any different between a client_id URL being local vs any other URL being local? If we allow loopbacks in other places, why not there? (Haven’t given it much thought other than this question. If I am being dumb, point it out!)
gRegor Are the IndieAuth updates on https://indieauth.spec.indieweb.org/ or just in github commits?
capjamesg[d] What are the use cases for https://indieweb.org/IndieAuth_Ticket_Auth?
Seb[d] I think that one is the newest iteration in trying to solve private feed fetching
[fluffy] I made a very simple page submission system for novembeat.com which exposed a lot of issues in how I was assuming that content updates work, and I'm now thinking the file watchdog is kind of a mistake. Or at least shouldn't run in production, and that production sites should be explicitly reindexed.
GWG IndieAuth metadata adopts OAuth 2.0 Authorization Server Metadata [[RFC8414]], with the notable difference that discovery of the URL happens via the IndieAuth link relation rather than the <code>.well-known discovery</code> method specified by RFC8414. For compatibility with other OAuth 2.0 implementations, use of the <code>.well-known</code> path as defined in RFC8414 is RECOMMENDED but
jamietanna I've implemented it as such at https://indieauth.jvt.me/.well-known/oauth-authorization-server but it just has to be rel=indieauth-metadata or a `link` header of the same name
[schmarty] dashes++ underscores--
Zegnat Hmm, I guess that is some sort of usage narrowing then. A token without scopes does not grant you any priveledges. So it to me maps to an identity token. If the token does nothing other than showing your identity to me, I am not sure I will ever care on which URL you are telling me your identity. So I guess I wouldn’t immediately think to get a resource associated with it.