#dev 2021-07-10

2021-07-10 UTC
jeremycherfas, hendursaga, vilhalmer, alex11, geman, gerben, neocow, eco, mikeputnam, strugee, doosboox, petermolnar, capjamesg, hendursa1 and jjuran joined the channel
#
capjamesg
I have a somewhat unique problem that I need help with.
#
capjamesg
I'm building a search engine for my blog (https://search.jamesg.blog). The engine functions as intended except for one feature I'd like to add: image search that lets you see images.
#
capjamesg
The trouble is that my images are quite large so loading them on the image search would result in quite a bulky page.
#
capjamesg
Is the best way to do this to create small thumbnail images to show in search on crawl?
#
capjamesg
Or is there something else I can do?
#
capjamesg
Got it. I can use the PIL library to create thumbnails to show in search.
j9hs joined the channel
#
Zegnat
Oh, that is interesting. Wondering if anyone else has separate search results for types on their blogs
j9hs, hendursaga and j9hs_ joined the channel
#
capjamesg
What is search?
#
Loqi
search in the context of the IndieWeb refers to being able to search your personal site for your own content https://indieweb.org/search
#
capjamesg
Zegnat the wiki hsa a bit on this I just found ^
#
Zegnat
Yeah, I was mostly wondering with regards to your type=image, which I do not think anyone on there has?
#
capjamesg
I don't think so.
#
capjamesg
I added type=image because I thought that images should be distinct from posts, as they are on Google.
#
capjamesg
I'll probably add my example to the wiki.
#
capjamesg
(And images are stored in a separate virtual table as a result of my wanting to keep them distinct from posts)
j9hs_ joined the channel
#
capjamesg
Now adding breadcrumbs...
#
capjamesg
284 pages indexed, 226 images indexed. I think I'm about done for now.
j9hs_, jamietanna and [snarfed] joined the channel
#
[snarfed]
I’ll just leave this here for create day: https://bridgy.readthedocs.io/#adding-a-new-silo
#
GWG
I'm looking forward to doing some auth and a few other things
#
capjamesg
Odd question for everyone: is there a correct way to mark up search results :D
#
capjamesg
(I meant to say ...mark up search results with microformats)
#
capjamesg
Doesn't look like it. I was just curious :D
#
GWG
capjamesg: An h-feed would work
#
capjamesg
Thanks GWG!
capjamesg, sknebel, j9hs_ and [KevinMarks] joined the channel
#
aaronpk
GWG: i see you have a indieauth ticket receiver according to the wiki, what is the URL I would send a ticket to?
#
GWG
aaronpk: You can discover it at https://wpdev.gwg.us
#
GWG
Although I am working on the code right now.
#
capjamesg
What's everyone working on?
#
GWG
Since I'm adding a class to manage the token store, the code that stores it now is still working.
#
capjamesg
I don't want to disrupt anyone's flow :)
#
[KevinMarks]
what shoudl I read to understand the ticket thing you're all making?
#
Zegnat
If you now request my homepage with an authorization token, my display photo should swap out for a picture I just took before :D I wanted to do this to show of my new hair colour, but I need much better lighting :(
#
Zegnat
It will also put a little "welcome $URL" at the top, so you know you are browsing the page in logged in mode
#
Zegnat
I am using https://addons.mozilla.org/en-GB/firefox/addon/modheader-firefox/ to manually add an Authorization header while browsing.
#
capjamesg
Zegnat It's been a while since I read up on SQL injection so I'm just briefing myself.
#
capjamesg
For now I'm not going to deploy the inurl change. I don't know how many people would use it -- including myself!
#
capjamesg
So now I'm just cleaning up my blog so it's primed for indexing.
tracydurnell joined the channel
#
sknebel
is there any obvious reason why I shouldn't just use code to create and hand out auth codes to hand out tokens?
#
sknebel
is there any obvious reason why I shouldn't just use code to create and hand out auth codes to hand out tokens for tokenauth?
#
sknebel
tickets, sorry
#
sknebel
ticket is pretty much the same, just that it push it on the other site instead of it asking, right?
#
aaronpk
i don't remember 🙈
#
Zegnat
grant_type=authorization_code has requirements that aren’t met, I think?
#
Zegnat
Is my vague first answer :P
#
sknebel
so this way around is fine? :P
#
sknebel
realistically I shouldn't use this code because whoever wrote it was an idiot who wrote hard to understand code I'm not actually sure it does it right
#
sknebel
(yes, I know, I wrote the code...)
#
Zegnat
ticket is pretty much the same as code, but with grant_type authroization_code the spec requires e.g. redirect_uri to be set. So I think really the only reason for ticket is to use a different grant_type and being able to separate the two paths that led to a valid token
#
Zegnat
is reading Token Introspection again and comparing to IndieAuth token verification and having thoughts^{tm}
#
Zegnat
So here is a question: is anyone using token verification requests for anything?
#
aaronpk
well that's how Aperture is able to verify tokens from my site
j9hs joined the channel
#
GWG
Zegnat: I just built token verification. Does your endpoint support it?
#
Zegnat
I was just thinking because it does not follow some of the security considerations of token intropection, which is basically the same thing but a separate OAuth extension
#
Zegnat
GWG: no, my resource servers just access the db directly so I do not need to support that
#
aaronpk
so for Aperture to support the OAuth token introspection spec, I would need to create an additional setup step for people to enter some sort of credentials from their token endpoint into Aperture so that it could make authorized introspection requests
#
sknebel
token introspection is "trusted" access to see details about a token?
#
sknebel
i.e. "I'm a resource you are responsible for, please tell what I need to know about this random token someone is trying to use"?
#
Zegnat
And you need to be authenticated because otherwise it opens up for token phising etc
#
aaronpk
it's debatable how much that really matters though because you can just as easily try random tokens at the resource server
#
sknebel
right, that's what I'm wondering. I guess you might not want to tell the token owner that they are in the group "untrustworthy_employees"?
#
aaronpk
then the resource server will add its credentials and send the request to the introspection endpoint anyway
#
sknebel
if thats a thing the token contains
#
aaronpk
but yeah the more interesting question is that
#
aaronpk
how much of the token details you want to expose to the application and end user
#
Zegnat
I was also thinking about this because I am thinking of ticket auth, and if more information might end up in that response
#
sknebel
hm, I think I can justify breaking support for the private webmention spec only sebsel ever implemented while doing this :D
#
Zegnat
Also re refresh discussions, about maybe putting expiration time in the token verification response. I just feel like there is a risk where a fuzzy line is crossed and we might leak too much token information public.
#
Zegnat
But maybe not that big a concern. I was just wondering if it could go the way of other older features and be dropped from indieauth if nobody is using it (all introspection happens proprietary behind the scenes) and we could just point at the introspection spec for interop
#
aaronpk
there is definitely use of it currently with aperture
#
sknebel
what does aperture do with it?
#
aaronpk
and not just me
#
aaronpk
aperture has to verify tokens somehow, the tokens are issued by people's own endpoints
#
aaronpk
(aperture is a resource server in this case)
#
sknebel
ah, sure
#
aaronpk
ok i think i have enough framework/boilerplate to actually send an indieauth ticket and issue a token now :)
#
aaronpk
(2 hours later)
#
aaronpk
goes back to the ticket auth spec page
#
sknebel
ah, hm, I still use tickets.indieauth.com for my main page. so I need to send tickets for other urls, not for that :D
[fluffy] joined the channel
#
[fluffy]
My tickets/tokens are a signed content blob (using ItsDangerous), and only contain the identity, the scope, and the expiration. All other access information is purely managed server-side.
#
aaronpk
i'm doing this entirely server-side with random strings for everything
#
[fluffy]
Yeah that’s even better
#
aaronpk
well, "better" considering certain priorities
#
[fluffy]
Eventually I want to add the option to make pure-server-side token storage to Publ, it’s just that I have an underlying design decision that Publ should be as stateless as possible.
#
[fluffy]
I did eventually add an abstraction to Authl to allow stateful token storage as a configuration thing and I plan on putting that in Publ too. And Publ can use stateful sessions since that’s a standard Flask feature, but tokens use a different mechanism.
#
[fluffy]
Publ tokens basically reimplement Flask sessions the long way around, which is annoying but I couldn’t figure out how to use Flask’s built-in stuff without committing some major layer violations.
#
GWG
I just added the code to delete tokens from my external token store when expired, only allow the user who owns the store to retrieve tokens from it, and if there's a refresh token, to try to redeem it on expiry.
#
GWG
Since [fluffy] sends refresh tokens
#
[fluffy]
The way I implemented refresh tokens, once the original token expires, so has the refresh token. Is the general guidance that the consumer should refresh before expiration, or that the producer should provide some leeway?
#
aaronpk
the idea with refresh token is that they last longer than the access token
#
aaronpk
otherwise there's no point in a refresh token
#
[fluffy]
How much longer should it last?
#
aaronpk
it's meant to last for the duration of the authorization being granted
#
aaronpk
whereas you may want an access token to last significantly shorter than the authorization
#
[fluffy]
I was taking my intuition from how WebSub refresh tokens work, where it’s up to the consumer to refresh before it expires, rather than up to the producer to honor a refresh token that’s already expired.
#
aaronpk
so you might say "I am authorizing this micropub client to create posts on my website indefinitely" but you might not want access tokens to last forever
#
[fluffy]
like the way things stand in Publ, when you get a token, the access token will have an expiration of, say, 1 month, and the refresh token will also have an expiration of 1 month, and you can use the refresh token to acquire a new access token before the access token expires.
#
aaronpk
ah, the "expire if not used by" model works too
#
[fluffy]
Given that refresh tokens don’t even exist in the indieauth spec right now, I feel comfortable waiting for use cases and semantics to be settled better 🙂
#
aaronpk
i still don't think there is any need to define any specific behavior about refresh tokens in indieauth
#
aaronpk
as far as i can tell there is nothing unique to indieauth about anything to do with refresh tokens
#
[fluffy]
I was just defaulting to how WebSub refresh tokens work because that’s the first spec I ever implemented that spelled it out
#
[fluffy]
Yeah it’s just that like… the way that tokens are used for ticketauth is different than how they’re used for, say, micropub, apparently
#
Zegnat
I would need to check up on WebSub. It feels a little weird to me. Intuitively I would be using an access token all the time, until I hit a 4xx with it, then I will dig up the refresh token to get myself a new one. If the refresh token then fails, I need to go request authorization from scratch.
#
[fluffy]
or at least that’s what I’m inferring from your micropub example
#
[fluffy]
I could also be misremembering websub
#
aaronpk
well with ticket auth the idea is we are issuing tokens for other users, rather than issuing tokens for apps to post to your own account
#
aaronpk
so it's quite different than micropub (delegated authorization)
#
[fluffy]
Yeah that’s what I was inferring 🙂
#
aaronpk
but still nothing particularly special about refresh tokens in either case
#
[fluffy]
okay I was misremembering websub’s expiration thing
#
Zegnat
Once you have redeemed the ticket at the token endpoint, we are back in default OAuth 2.0 land, I think?
#
aaronpk
yep ticket auth is just a different way to get an access token (and potentially could include a refresh token too)
#
[fluffy]
In websub, the lease_seconds just tells you how long the subscription will stay active, as guidance to the consumer for when to initiate a new subscription request. There’s no such thing as a refresh token in it.
#
[fluffy]
and in Feed On Feeds I chose to make it preemptively refresh the subscription at poll time if it’s about to expire.
#
GWG
I still want IndieAuth to reference the refresh_token spec.
#
GWG
Zegnat: By the way, used that Firefox addon to get your alternative picture
#
aaronpk
indieauth can mention refresh tokens but there's nothing to reference since it's not adding any new behavior about refresh tokens
#
Zegnat
GWG: aah, it worked? Always good to have someone else confirm it! :D
#
aaronpk
also refresh tokens are part of the core oauth 2 spec, so technically they are already referenced by indieauth
#
[fluffy]
I like when specs provide the information about the “see also” for other specs that they rely on
#
aaronpk
("reference" is a magic word in specs)
#
[fluffy]
like as someone who’s implementing indieauth directly but gives approximately zero craps about the underlying OAuth it’d be nice for the section to at least call out the “see more” from the original spec.
#
Zegnat
I found it very hard to implement IndieAuth without implementing OAuth. Had to do lots of dives into OAuth for error responses and the likes
#
[fluffy]
Odd, that wasn’t my experience at all
#
[fluffy]
Anyway I think that if the IndieAuth spec on token grants were to point to the OAuth spec on token grants with language like “IndieAuth tokens also support token refresh per [the OAuth spec](blahblahblah)” that’d be satisfactory to me. I had no idea refresh tokens were even an option until GWG opened the issue.
#
GWG
[fluffy]: That's what I was pushing for.
#
GWG
Also, whether or not we should recommend expiring tokens
#
[fluffy]
yeah, and what the expiration time on a refresh token should be
#
[fluffy]
I’m getting the impression that a refresh token’s expiration should be longer than the authorization token’s, but how much longer?
#
[fluffy]
I refuse to issue a token without expiration, because that feels like a really bad security problem to me.
#
aaronpk
this is another thing that is a question not unique to indieauth
#
aaronpk
so all regular oauth advice about token lifetimes applies
#
[fluffy]
Where can I see that advice?
#
aaronpk
i know a good book ;-)
#
aaronpk
and some workshops you can attend :D
#
GWG
aaronpk: Shall I run and fetch it?
#
Zegnat
The first thing that comes to mind to me is that selfauth implements errors wrong, as apparently you need to redirect back to the client and include state: https://github.com/Zegnat/php-mindee/blob/7638c598a0627e49c31e6f61c4e9e267f551d307/index.php#L86-L102 Typical thing that was never clear to me from the indieauth spec alone.
#
[fluffy]
ah, yeah, I can see IndieAuth providers being a lot more complicated than clients. I’ve only done the client side of things.
#
[fluffy]
well, aside from the token endpoint in Publ, which only implements the tiny subset necessary for Ticket Auth.
#
GWG
aaronpk: As the spec editor, would linking to various recommendations be an issue for the next revision?
#
[fluffy]
Supporting Micropub in Publ is gonna be weird because Micropub uses a token grant from the IndieAuth provider, but Publ isn’t actually integrated with the provider. Like I use SelfAuth to log in to my own Publ instance.
#
[fluffy]
I guess it could do something like get a token from the user’s IndieAuth provider and then use that to grant a Publ token?
#
[fluffy]
well, like, get the token, then verify it, then go “okay you’re cool, here’s a token for reals”
#
[fluffy]
I still don’t quite understand the Micropub flow though.
#
aaronpk
GWG: yes editorial changes like that are a good idea
#
[fluffy]
I’ll probably understand it better when I get around to implementing Micropub for Publ (MicroPubl?)
#
Zegnat
I think nothing in Micropub requires IndieAuth. It just mentions IndieAuth as a way to obtain a token, and that is what most (all?) Micropub clients now require.
#
GWG
aaronpk: I think I'll go create a page for next month's popup, if there isn't one.
#
aaronpk
correct, indieauth is a way to get an access token, ticket auth is a way to get an access token, and you could also get an access token using oauth core, or the oauth device flow, etc
#
GWG
There is not.
#
[fluffy]
okay, so the problem for Publ’s weirdness is that the indieauth token_endpoint isn’t going to be the same as the ticketauth token_endpoint
#
GWG
By the way, there is now a Microsub popup wiki page for people to put possible topics.
#
GWG
Going to clone it into an IndieAuth page
#
Zegnat
[fluffy]: it does not need to be. You do not even neccessarily need a token_endpoint for Micropub at all.
#
[fluffy]
Publ’s token_endpoint assumes it already has a valid identity provided by external means.
#
[fluffy]
Oh, interesting. So could there be a client that lets you give it a token in some other way?
#
[fluffy]
I mean you said that already yeah bu tlike
#
[fluffy]
Are there any clients which would be amenable to a flow other than “sign in with indieauth, then use that same site’s token_endpoint to get a token from the indieauth instance”
#
Zegnat
I think Omnibear might have had the option to just drop a token into a form instead of doing IndieAuth
#
[fluffy]
like there’s probably some major disconnect that I’m not understanding here but on my site the authorization_endpoint points to SelfAuth but the token_endpoint points to Publ, and Publ knows nothing about how SelfAuth validates an identity.
#
[fluffy]
but I’m thinking that Publ *could* go “okay this thing is asking for an access_token against this identity with this authorization code, I’ll look up that identity’s authorization_endpoint and token_endpoint and use that to validate the code”
#
[fluffy]
but this has all been a low priority for me anyway since I don’t personally care about using micropub to post to my site. I’d love to support micropub so that other people have less friction in using Publ though.
#
[fluffy]
And also that might be nice for social reader integration.
#
aaronpk
GWG: sorry for the random requests i'm throwing at your site right now :)
#
GWG
aaronpk: I didn't even notice
#
sknebel
GWG: would your endpoint parse the ticket endpoint out of an error page?
#
sknebel
sorry, token endpoint
#
sknebel
stupid words with the same letter
#
Zegnat
It is definitely a balancing act of wants and needs et al. IndieAuth is an extension to OAuth for letting unregistered clients discover the correct OAuth endpoints to be able to request tokens. So if you want to support IndieAuth as a way for clients to request tokens, the must be a way for the authorization_endpoint and the token_endpoint to speak to eachother.
#
GWG
aaronpk: It says it can't find the token endpoint, I believe.
#
GWG
That's the issue Zegnat and I had earlier.
#
aaronpk
correct, thank you for the nice error message in the response
#
aaronpk
i haven't defined the token endpoint yet :)
#
GWG
sknebel: I just checked. It does.
#
GWG
sknebel: I probably should check the response code. I only check on discovery for 300 series
#
aaronpk
GWG: looks like you've got some unhandled error cases "There has been a critical error on this website"
#
sknebel
its useful, because private parts of my site give you an error if you dont auth
#
GWG
aaronpk: I'm checking the logs now.
#
aaronpk
my website is not responding properly so i'm not expecting it to work, but i would also not expect server errors :)
angelo joined the channel
#
GWG
aaronpk: Thanks. I didn't account for the function passing back an OAuth Error Object
#
GWG
I have to update some of the error responses. I wasn't sure what to say, so I think I copy-pasted a few.
#
GWG
It should return something now. Just not what you want.
Zegnat joined the channel
#
sknebel
hm "'{"error":"indieauth_response_error","error_description":"This is not working correctly"}'"
#
aaronpk
better than a 500 error :)
#
sknebel
401, yeah
#
GWG
I was returning the error, but the system was treating it as a success.
#
GWG
I'm updating the error messages now
#
[fluffy]
One reason why I don’t want to integrate the IndieAuth authorization_endpoint into Publ is that Publ itself is just the site publishing engine, and it’s not necessarily going to be for a single-author site. Like one specific reason I do want to support Micropub is to allow a community blog sort of thing. I’m not sure if that’s compatible with how Micropub clients expect identity to work though.
#
Zegnat
aaronpk: I currently store the ticket endpoint I sent a ticket to as the "client"
#
Zegnat
Should probably write that in the issue :P
#
sknebel
GWG: was that a success? I see your site made requests for a token
#
aaronpk
please do :)
#
GWG
aaronpk: I wrote my thought in the issue.
#
aaronpk
[fluffy]: there's also nothing about micropub or micropub clients that assume single-user websites
#
sknebel
ah no, seems my code failed to handle the request :/
#
GWG
sknebel: Yes. I'm fixing the error messages to be more helpful now
#
[fluffy]
[aaronpk] yeah but I mean like… don’t micropub clients all at least assume that you’re going to be signing in as the identity of the site itself? Or if not, that’s probably where my massive disconnect lies.
#
aaronpk
no not really, the micropub client doesn't really care what identity you're signing in as, because it's not trying to know *who* you are, it's trying to get an access token to be able to create posts at the micropub endpoint
#
[fluffy]
okay but that’s still where there’s a weird little edge case in supporting Micropub on Publ… let me try to flesh out an explanation of why this is weird to me
#
aaronpk
in practice, some micropub clients will show the "me" URL to show the user which site they are posting to, but that URL could be a user-specific URL on the site, or could be the site's home page, it doesn't really matter
#
Zegnat
Most (all?) Micropub clients use IndieAuth to discover the authorization_endpoint, but that is just the place they send their user to authorize a token. sink.zegnat.net for instance will let users write in their own site address and do IndieAuth with their own setup rather than relying on an identity issued by sink.zegnat.net itself
#
[fluffy]
If someone tries to post to beesbuzz.biz, they’d be asking beesbuzz.biz’s token_endpoint for an access token to post to it, right? And that token has to go through some sort of authentication flow to make sure that the token is valid, which it would do presumably by asking that someone’s IndieAuth endpoint.
#
Zegnat
GWG: I think I was wrong before, I do support token verification, I do not support revocation
#
GWG
I wonder why my code didn't work though.
#
[fluffy]
And that’s all well and good with how things are set up… but then if *I* try to post to beesbuzz.biz, my IndieAuth identity (validated by SelfAuth) is also beesbuzz.biz, and so my token_endpoint would appear to be publ’s, not SelfAuth’s
#
[fluffy]
and again I probably am fundamentally misunderstanding the authorization flow for micropub
KartikPrabhu joined the channel
#
[fluffy]
but my understanding is that there’s some dance that occurs with the token_endpoint provided by the user’s identity URL
#
[fluffy]
and that it’s an “implementation detail” about how the identity URL’s token_endpoint and authorization_endpoint talk to each other
#
[fluffy]
but like, beesbuzz.biz as an identity would have a different token_endpoint than beesbuzz.biz as a resource.
#
GWG
[fluffy]: If they are not integrated, there is what was used in the earlier version of the spec, which so far no one turned into an extension
#
[fluffy]
The obvious workaround would be for me to have a separate identity URL for signing in to my own site
#
aaronpk
token endpoints are not part of identity, they are only part of authorization of access to resources
#
[fluffy]
okay, so how does a token_endpoint grant a token against an identity?
#
Zegnat
You probably only want to trust tokens from publ’s own token endpoint for micropub requests to publ. Trusting tokens created by external token endpoints might be risky, as they can claim to be for any value of `me`. So you need impersenation checks etc.
#
aaronpk
that's between the two endpoints to figure out
#
aaronpk
which typically are part of the same software, so it's an "implementation detail"
#
[fluffy]
see, that’s the problem, I don’t want Publ’s token endpoint to have to know how to talk to every IndieAuth authorizatoin_endpoint
#
aaronpk
this is why there was originally a part in the indieauth spec that described how the two endpoints can talk to each other, which is how tokens.indieauth.com works
#
[fluffy]
Like in this case, Publ is explicitly *not* part of the same software as the IndieAuth authorization_endpoint
#
aaronpk
wait Publ is your token endpoint?
#
[fluffy]
yes, because Publ is providing the tokens for TicketAuth
#
Zegnat
I would expect to point a Micropub client at a Publ site, end up on a login page provided by Publ (the authorization_endpoint), when I login there (proofing my identity in some way to Publ) I will be redirected back to the Micropub client with a code. The Micropub client then exchanges the code against Publ‘s token_endpoint to get a token to send along with Micropub requests.
#
[fluffy]
[Zegnat] but Publ doesn’t provide an authorization_endpoint
#
[fluffy]
and it *can’t*
#
aaronpk
so if you want to continue down the path of completely separate and interoperable token and authorization endpoints, you'll need a contract between the two, which we've moved out of the core indieauth spec but could be done as an extension
#
aaronpk
personally i am not interested in continuing to support tokens.indieauth.com or that model, so i have no interest in that extension, but that's not to say someone else couldn't take it and run with it
#
GWG
aaronpk: Did we dump it into a wiki page somewhere for reference?
#
[fluffy]
IIRC the tokens.indieauth.com approach isn’t workable either though, and I’m having too much difficulty articulating it and should probably give up again before I get frustrated and another giant pain flare from this
#
Zegnat
I guess I do not understand why publ can’t support a login box at the authorization_endpoint. Which is all it would need to be able to issue tokens
#
[fluffy]
but anyway the tl;dr of the problem as I see it is that beesbuzz.biz-as-identity is different than beesbuzz.biz-as-resource as far as what the token_endpoint should be
#
[fluffy]
because beesbuzz.biz’s authorization_endpoint points to my SelfAuth because that’s what I’m using to sign in to my site
#
[fluffy]
I don’t want to give user accounts to my indieauth endpoint for everyone who might be posting to my site
#
[fluffy]
I want them to be signing in with their own identities
#
[fluffy]
I purposefully do not want publ to be in the business of providing identities beyond the profile URL
#
[fluffy]
if publ provides an authorization_endpoint that then lets people proxy a login to their own identity then anyone can just log in as me if they’re able to log in to my site.
#
aaronpk
if you want other users to sign in to beesbuzz.biz, that site would be acting as an indieauth *client* and would go discover the authorization endpoint of the user
#
[fluffy]
argh this is frustrating
#
[fluffy]
beesbuzz.biz does act as an indieauth client, for when people sign in to look at private entries
#
[fluffy]
but it declares an authorization_endpoint so that *I can sign in as myself to other sites*
#
aaronpk
right, that's fine
#
[fluffy]
maybe beesbuzz.biz is a bad example for this
#
[fluffy]
because I have no interest in allowing other people to post to it anyway
angelo joined the channel
#
aaronpk
i guess i don't see the problem then? this seems like it works
#
[fluffy]
but like. beesbuzz.biz lets people sign in using indieauth (among other things) as an indieauth client, but it also provides an authorization_endpoint that lets me sign in to other things.
#
Zegnat
Aah. Hmm. I see now. You would want authorization_endpoint both to be your Selfauth instance because you want to use beesbuzz.biz as your identity. But for the IndieAuth multi-user workflow you would also want the authorization_endpoint to point at the external-user login form.
#
[fluffy]
but it also provides a token_endpoint for TicketAuth, but that token_endpoint knows nothing about how to talk to the authorization_endpoint.
#
[fluffy]
[Zegnat] Yes, exactly
#
[fluffy]
well, I think
#
aaronpk
this multi-user situation, is that like a theoretical group blog?
#
aaronpk
so in that case there are two indieauth/oauth flows happening
#
aaronpk
one from the micropub client to the group blog, and a second from the group blog to each user's own authorization endpoint
#
[fluffy]
right, and I think in the case of a theoretical group blog, nobody would be signing into that blog as that blog’s own identity
#
[fluffy]
so this *might* be a non-issue. but it’s something that trips me up when I think about it too hard.
#
aaronpk
how the user authenticates at the authorization endpoint is not described in oauth or indieauth, intentionally
#
aaronpk
that authentication could be username/password, or it could be relmeauth, or it could be another indieauth flow
#
Zegnat
So sink.zegnat.net is a group blog in that way. So its authorization_endpoint is actually an IndieAuth login page and lets anyone login. Then when they are logged in the sink.zegnat.net token_endpoint can issue a token matching their identity (because they have proven who they are). But that obviously would not work if the sink.zegnat.net authorization_endpoint was also the thing I personally wanted to use to proof my own identity.
#
[fluffy]
okay so I’m thinking, then, that the authorization_endpoint on a group blog could even just point to an Authl signin page and people could therefore use non-IndieAuth identities to sign in for this
#
Zegnat
Crap, ignore me, my IRC is on the fritz so I have no idea when my messages come in compared to the conversation others are having :(
#
[fluffy]
yeah. I’m fine with just not supporting the use case of a group blog that is also an individual identity.
#
aaronpk
that does seem like a weird case
#
aaronpk
but i think you could still do it
#
[fluffy]
There’s still the issue that like… if a group blog has an authorization_endpoint that accepts any login to it, then theoretically *anyone* could use that group blog to identify to another site (even if they aren’t granted post access to that group blog)
#
aaronpk
you'd only send a "me" URL as the root URL when *you* log in, and you'd return URLs with paths for all the other users
#
[fluffy]
but I guess that’s just something to keep in mind for a group blog site - to only authenticate people known as authors on the blog.
#
aaronpk
the authorization endpoint is the one that decides what "me" URL to send back to the client, and it can use whatever criteria it wants to make that decision
#
sknebel
GWG: "500 {"error":"unknown","error_description":"Unable to Store External Token"}"
#
sknebel
that epxected right now?
#
[fluffy]
oh, that’s a good point
#
[fluffy]
Wait but the me URL thing won’t work because of how ‘different profile URL’ works
#
aaronpk
the key here is separating this out into the two oauth flows rather than thinking about it as one single flow
#
aaronpk
the group blog would have to use author sub-pages for the other users
#
GWG
sknebel: That means I couldn't figure out who you were sending the token to. Was there a me property in the redeemed token?
#
[fluffy]
yeah but then that gets back to the problem of requiring people to have a means of signing in to their author page identity which may or may not be IndieAuth. I suppose that could b epushed down a layer and the author profile can have a list of allowed third-party identities.
#
aaronpk
that's not a problem, that's just a thing
#
[fluffy]
That *slightly* complicates things but like… yeah
#
sknebel
GWG: ah, good point :D
#
GWG
sknebel: Gave me another error scenario
#
Zegnat
GWG: are you writing them all down? ;)
#
[fluffy]
in the case of Publ I was definitely going to be making the Micropub stuff in a separate library that would only be optionally pulled in so that means this doesn’t have to complicate Publ itself. and it can provide a route like /_author/<name> which provides their h-card and whatever, and is configured at an admin level such that <name> maps to third-party identities.
#
sknebel
GWG: HAH, now. you should have a token for https://www.svenknebel.de/testing/autoauth
#
sknebel
(it also should work on other things, but I dont think I have any private posts shared with you :/)
#
aaronpk
hah wait what "me" am I supposed to return when issuing a token this way
#
GWG
sknebel: I do.
#
aaronpk
this would be the user i am granting access to right?
#
GWG
aaronpk: Yes.
#
Zegnat
aaronpk: yes, that is what I do at least
#
aaronpk
that's the "subject" right?
#
GWG
So, me= the original subject
#
[fluffy]
You wrote the spec!
#
GWG
aaronpk: That's what I thought.
#
Zegnat
Or well, not really, my me=subject=place where ticket endpoint is declared.
#
Zegnat
Not really as in, it might not be the subject‘s actual prefered me
#
GWG
[fluffy]: He wrote IndieAuth. Ticket Auth is still a thing.
#
GWG
Zegnat: Point taken
#
[fluffy]
Aaron wrote the Ticket Auth draft spec on the wiki :P
#
aaronpk
i did write most of ticket auth too but this was the first draft 😂 https://indieweb.org/wiki/index.php?title=IndieAuth_Ticket_Auth&oldid=70851
#
[fluffy]
oh wait then who added subject=?
#
aaronpk
it mentions subject
#
aaronpk
hey i think it worked
#
aaronpk
GWG i got an empty array as a response
#
GWG
aaronpk: Yes. I haven't decided what to put in the response body.
#
GWG
Any ideas?
#
GWG
How should a ticket endpoint respond to accepting a ticket?
#
GWG
I could put a fun message
#
[fluffy]
IMO anything with a 200 response should be fine
#
aaronpk
i think this is going to be like webmention where the body isn't really important
#
GWG
That's why mine was empty.
#
GWG
But I'll put a message in. Why not...
#
[fluffy]
the ticket issuer isn’t going to do anything based on what the ticket endpoint replies with, and 200/202/whatever and fun message seems :thumbsup: to me
#
aaronpk
but yeah it's helpful to inclue some sort of message to tell people who are looking at the responses when writing code
#
Zegnat
As with webmention, it could signify whether the ticket is send synchronous or asynchronous, I guess?
#
aaronpk
that's HTTP 200 vs 202
#
aaronpk
but functionally there isn't any need for a response body, it's just nice for debugging
#
[fluffy]
Publ’s ticket_endpoint has a “request a ticket” function and its positive response is just “Ticket sent” with an HTTP 202
#
aaronpk
i forgot that i already implemented this in my actual website
#
GWG
There.
#
GWG
It now has a special message if it works
#
aaronpk
lol nice "Your Ticket Has Been Redeemed. Thank you for your trust!"
#
[fluffy]
although I should probably change the URL parameter for the ticket request thing… right now it’s just ‘me=’
#
[fluffy]
and that feels like it might be overloaded by something else
#
[fluffy]
so like https://beesbuzz.biz/_tokens?me=https://example.com will issue a ticketauth flow for example.com
#
aaronpk
ok, now i can move on to receiving ticket requests and storing tokens
#
[fluffy]
s/issue/initiate/
#
GWG
I still want to brainstorm at some point on how you actually use the token once you have it
#
aaronpk
protected posts, protected feeds, etc
#
[fluffy]
and yeah I am very tempted to add a ticket endpoint to Feed-on-Feeds, even though I really want a reason to finally work on my reader project.
#
aaronpk
that's the easy part
#
GWG
aaronpk: No, how you get it to your client.
#
[fluffy]
yeah, include the token when fetching a feed, and then your reader gets populated with authorized private posts.
#
GWG
Or how your client gets it
#
[fluffy]
but yeah in the common indieweb protocol pile the token should be retained by the microsub implementation
#
[fluffy]
or whatever’s fetching the feed, anyway
#
GWG
So, your ticket endpoint has your token, so in theory, your client should be able to query your ticket endpoint to get it.
#
GWG
That's the next flow to think about.
#
Zegnat
Your browser goes and gets the token so it can send it when you are navigating the other persons site, GWG :D
#
GWG
After we answer some of the remaining ticket auth questions we have
#
GWG
Zegnat: This is the...how does it get it question.
#
GWG
And where does it get it from
#
aaronpk
some of these answers will be "internal logic"
#
GWG
aaronpk: That only works if your ticket endpoint is integrated into the thing that is doing the reading
#
aaronpk
correct
#
aaronpk
but it also means that those answers probably don't need to be in a spec
#
GWG
What if I have a ticket endpoint, but I'm using Aperture as my microsub endpoint and want to hand the token over to it?
#
Zegnat
That is when you enter "autoauth levels of multidance" again :D
#
aaronpk
if we want interoperability between things then there needs to be a spec for it
#
GWG
That's what I was asking about.
#
[fluffy]
My assumption with all this all along is that the ticket endpoint was going to be provided by the reader and not be its own standalone thing
#
[fluffy]
er, ‘reader’ meaning ‘thing that pulls feeds’
#
[fluffy]
which I realize is at odds with most indieweb readers
#
GWG
[fluffy]: That's an interesting thought.
#
aaronpk
my assumption is that either everything is bundled into a single piece of software (e.g. wordpress with a built in reader), or all authorization stuff is a standalone thing that is used by all the various parts
#
GWG
But [fluffy]'s thought makes sense. If the ticket endpoint is integrated with the Microsub endpoint. I've been integrating mine with my token and auth endpoint code.
#
aaronpk
but this isn't only about fetching feeds
#
aaronpk
you could use it with webmention too
#
GWG
Yes.
#
[fluffy]
true, that’s where things get trickier
#
[fluffy]
I’ve been sort of avoiding thinking about the webmention side of things because I feel like mixing webmention and private content is inherently risky
#
aaronpk
i think i am going to add an endpoint to my new app so that my website can ask "do you have an access token that might work at X resource", that way it could be used for feed fetching as well as webmention
#
GWG
So, like the idea of having non-integrated authorization and token endpoints, that is another spec.
#
GWG
aaronpk: New app?
#
aaronpk
i'm building this stuff today as a new app
#
GWG
Oh.
#
aaronpk
it's eventually going to be a full indieauth server
#
[fluffy]
I keep meaning to add bearer token support to Pushl but it was going to be based on sideband token grants, rather than trying to use anything like ticketauth etc., but then the whole mention verification thing becomes difficult, etc.etc.
#
[fluffy]
like if I have a private post that links to another private post, Pushl needs to be able to see the source post, it needs to be able to get the mention endpoint of the target post, and the mention endpoint needs to be able to see the source post.
#
GWG
I may, after this is more stable, contemplate the idea of a second POST request to the ticket endpoint, with a required bearer token from my token endpoint, scoped to allow it to return the token in question.
#
[fluffy]
and even if all that stuff does work, in the common case you potentially have a public post that’s replying to a private post and then that causes drama/privacy violations/etc.
#
aaronpk
making all these parts modular and interchangeable is definitely adding challenges that don't need to be there for the basic interop to work
#
GWG
So, a redemption flow. I know that's one of the things AUTOAuth had trouble with
#
[fluffy]
thus why I prefer having native private comments on my site instead of using mentions for comments on private posts 😛
#
GWG
aaronpk: That's why I thought being able to redeem a ticket and get a token needed to work before the other stuff.
#
GWG
Because in some implementations, you don't need them.
#
GWG
It's certainly a case for integration.
#
[fluffy]
It’s really annoying when people post a public tweet in response to my private post stubs. So far there hasn’t been anything particularly awful from that, just the occasional “Oh, I’m sorry” in response to a “Private post: [akjdflkajsf]” tweet.
#
aaronpk
yeah twitter is not a good example of that, since public twitter accounts that reply to private tweets still have the public reply visible
#
[fluffy]
(And then those don’t come into my site because of https://github.com/snarfed/bridgy/issues/1012 although I guess that’s fixed now)
#
Zegnat
aaronpk: what sort of endpoint do you mean? You mean that Aperture could go to aaronpk.com and ask "is there a token for subject aaronpk.com at resource vanderven.se that I can use for fetching?"
#
Loqi
[fluffy-critter] #1012 allow webmention endpoint discovery on non-2xx responses
#
aaronpk
yes that
#
aaronpk
so that when aperture is fetching your home page for me, it could include an access token that you have sent me
#
GWG
aaronpk: What endpoint at aaronpk.com would it be asking?
#
aaronpk
well it would be an endpoint at my new authorization server
#
aaronpk
this does not need to be standardized, it's a private API
#
Zegnat
That is pretty close to the autoauth case, yeah. Probably with the difference that for autoauth, you would make that request, and then that endpoint goes of to the mentioned resource to see if it can request a token in your name
batkin joined the channel
#
aaronpk
but i need to receive tickets first so let me go finish that
#
aaronpk
Zegnat++ for the "Request a Ticket" page
#
Loqi
Zegnat has 20 karma in this channel over the last year (59 in all channels)
#
sknebel
ok, and tokens also work for private posts on my site
#
Zegnat
I promised GWG a page that would let him request tickets, that became the page, haha
#
sknebel
GWG should be the only person able to read https://www.svenknebel.de/posts/2021/7/1/ right now :D
#
sknebel
(I did misremember did not allow seeing private posts in lists even if providing a token, I guess that needs fixing
#
GWG
I still need a nice and easy way to use the token
#
GWG
I have never written a Firefox plugin
#
batkin[m]
Going back to something I was trying to figure out several weeks ago - I'm wondering how to make it so I could enter any-subdomain.benatkin.com into a micropub client, and have it use the identity benatkin.com.
shoesNsocks joined the channel
#
sknebel
GWG: not that elegant, but the extension Zegnat recommended works for me https://addons.mozilla.org/en-GB/firefox/addon/modheader-firefox/
#
GWG
sknebel: That's what I was using
#
Zegnat
batkin[m]: have all of those pages point at the same authorization_endpoint, which results in me=benatkin.com
#
sknebel
"so that when aperture is fetching your home page for me, it could include an access token that you have sent me" - that's what autoauth had requests and extra scopes for
#
sknebel
which I think makes sense as a pattern still
#
GWG
sknebel: That was some of what I was thinking might work
#
Zegnat
It is really just a question of interop/standardisation for all those steps. And the question whether it even all belongs in the same spec or not. Ie. does it belong in TicketAuth or separate? Can it only work by having one huge sped like Autoauth? etc.
#
GWG
sknebel: In theory, if we wanted an external API, it could be a token scoped with a token requesting scope, that posted to the ticket endpoint to get back tokens.
#
GWG
Zegnat: Not sure.
#
GWG
Either it is part of ticket auth, or it's separate.
#
GWG
I think we have something good thus far.
#
sknebel
Zegnat: I seriously should have put the 3 "chapters" in separate files in autoauth, just to prevent peoples eyes from glazing over...
#
GWG
sknebel: You still can
#
sknebel
I kind of assume the damage is done
#
GWG
Well, I just broke something and erased my whole token list.
#
GWG
Time to test
#
GWG
My expiry check expired everything
#
GWG
Even if not expired
#
GWG
Okay. That's fixed.
#
GWG
Lost all my tokens, but that's a learning experience
#
GWG
I shouldn't dump my storage every 12 hours
#
aaronpk
oh here's a question
#
aaronpk
so i'm about to store this token that i'm getting from Zegnat
#
aaronpk
i need to also know where i got it from so that i have some limit to where i consider it to be valid for
#
aaronpk
in other words i don't want to let Zegnat give a token to my site that claims to be useful for gwg.us
#
GWG
That's interesting.
#
Zegnat
You should be storing the resource values from the first ticket request for that, surely? That is what it says "these resources should accept the token"
#
sknebel
that's the "resource" value in the ticket request
#
aaronpk
right, but i need some limit on who can claim what resource values
#
GWG
And that is where you are getting the token endpoint?
#
aaronpk
oh maybe that's already handled by the fact that the token endpoint is discovered from the resource URL
#
Zegnat
Ah, hmm, that is a lot harder. You would then want to go and check all the resource values to see which token_endpoints (if any) they mention?
#
Zegnat
Yes, as long as we stick to single resources, that solves that part
#
sknebel
that it's valid to the resource is checked that way
#
sknebel
what exactly counts *outside* the specific resource URL is tricky
#
aaronpk
so gwg can trick my site into requesting a token from zegnat but it will fail
#
GWG
It should.
#
Zegnat
Do we need to support the multi-resource case? Or should we just ignore that one?
#
GWG
Why do I have to be the malicious one in this example?
#
aaronpk
haha sorry
#
sknebel
part of why I went with what the HTTP spec says about "where is this auth valid" in autoauth
#
sknebel
(domain + realm)
#
sknebel
(we talked about this back then already :D)
#
GWG
I'm kidding.
#
GWG
But that is what resource is as well
#
Zegnat
I am trying to figure out if there is some sort of attack possible through multi resources, if we only ever check the first resource to find the token-endpoint, but would end up sending the token for requests to the second resource as well. Recourse 1 and 2 might be on different origins
#
Zegnat
But I can’t think of a case where it would actually be a problem
#
GWG
Let's say I send you a ticket that has a page on my site that delivers Zegnat's token endpoint. When I try to redeem the ticket, it will fail. How could that be an issue?
#
GWG
That's a good point.
#
GWG
Has anyone sent a multi-resource ticket?
#
GWG
I don't think I coded for that
#
batkin[m]
When trying to use micropub with a subdomain, and logging in with Quill, I got "The domain for the user returned did not match the domain of the user initially signing in"
#
aaronpk
ooh quill might not be updated with the latest indieauth client
#
batkin[m]
I never specified notes.benatkin.com as a user, the rel=me on that page is benatkin.com
#
aaronpk
Zegnat: how do i know if the token i got from you works? do you return something special on your home page?
#
sknebel
yes, his profile picture changes
#
Zegnat
aaronpk: yes, a different profile photo (trying to show off my new hair colour) and also a welcome line up top with your me
#
aaronpk
i don't have a good way of using this token in a browser :)
#
aaronpk
ah but i do see "welcome"!
#
GWG
aaronpk: That's the problem I was commenting on
#
Zegnat
I put a screenshot of what you would see in chat, did not want to put it in logged chat
#
GWG
None of us have built something for that yet
#
aaronpk
well cool this works
#
aaronpk
batkin[m]: let me take a look...
#
aaronpk
oh yeah quill is not ready to handle that
#
aaronpk
guess i can update that right now
KartikPrabhu joined the channel
#
batkin[m]
@aaronpk thanks
j9hs joined the channel
#
sknebel
thinking about it a bit more, I feel like "path below the resource" (or maybe even same origin) + "advertises the same token endpoint" works as "is this token usable here" best
#
GWG
sknebel: What about pages that 404?
#
sknebel
same rules
#
sknebel
advertise the endpoint
#
sknebel
(that also answers "who I do i need to ask for a token" once that comes up, which is pretty much *now* ;))
#
sknebel
(and use WWW-Authenticate generally to indicate "I might have more for you if you bring a token")
#
GWG
sknebel: You don't have to advertise though
#
GWG
That's a choice
#
sknebel
depends on how we define it :D
#
sknebel
you want some way to know if you should use the token or not
#
aaronpk
you could also always use the token once you know what resources it is for
#
Zegnat
I am not sure if "advertises" really is important, or if resource is enough. What is added by doing the check for the advertised token_endpoint?
#
batkin[m]
I got a token via a ticket from vanderven.se , by logging a request and using curl
#
batkin[m]
doesn't seem to have any easter eggs set up. or maybe just true easter eggs =)
#
GWG
So, does this mean that we've answered the question of where the ticket endpoint goes looking for the token endpoint?
#
GWG
If so, we can move that discussion
#
sknebel
Zegnat: it answers the "can i use this here"
#
sknebel
and it hints that you might want to try get a token
#
Zegnat
But doesn’t the fact that I have a token for the resource already hint at that? But yes, I do get it as a hint for "want to try get a token"
#
sknebel
Zegnat: well, depends on what "the resource" is
#
sknebel
right now it seems people mostly propose "resource" == "origin", thats very broad
#
GWG
sknebel: Resource as defined by RFC8707?
#
batkin[m]
I think I found something with my ticket token :)
#
sknebel
GWG: will almost always be your origin, because you want a reader to be able to read your homepage feed with token?
#
GWG
sknebel: Almost isn't always
#
sknebel
I don't think RFC8707 is really with our use case in mind
#
GWG
And again, it could aso be a token issued for a specific resource.
#
GWG
sknebel: That's a different use case for the same functionality.
#
GWG
sknebel: It probably isn't, but we could easily be compatible with it
#
sknebel
disagreed that we are looking for really the same functionality
[jgmac1106] joined the channel
#
sknebel
although maybe you can put it on the server operator to enforce that
#
sknebel
yeah, ok, I think I buy that argument
#
GWG
I mostly am thinking as you are. I want the token to cover the domain, and I can do individual ACLs for posts to see what I share.
#
GWG
But you also have the other non ticket auth reason for resources
#
GWG
For the IndieAuth server overall to consider
#
GWG
That's why I'm saying that resource is something for IndieAuth proper, not Ticket Auth, to establish
#
GWG
sknebel: You could want it to limit your token to only working with your Micropub endpoint.
#
GWG
Different flow, same property
#
aaronpk
resource and scope have similar uses for that case
#
sknebel
sure, I was thinking rules specifically for access tokens to fetch private content
#
aaronpk
we've essentially done what RFC8707 says is "overloading" of scope
#
GWG
aaronpk: We did? When?
#
aaronpk
when we defined micropub scopes
#
GWG
Did we?
#
aaronpk
the "create" scope implies the micropub endpoint resource
#
aaronpk
the resource indicator spec says if you don't want to overload scopes for this, here's how you can describe a resource instead
#
GWG
aaronpk: But create only implies the micropub endpoint because we don't currently have anything else using IndieAuth that creates
#
aaronpk
right, which is why it works
#
aaronpk
other services use full URLs as scope values which is also fine
#
GWG
This may be a good discussion for next month.
#
GWG
If not sooner
#
aaronpk
there isn't necessarily a problem here
#
Zegnat
Ooh, I forgot that mine actually shows the form field where I can write any me value I want: https://i.imgur.com/OmAdhzD.png
#
GWG
I need to update my photo
#
Zegnat
being required in its example request.
#
Zegnat
aaronpk: OAuth question, I am looking at RFC 7009 (revocation) for security considerations, to see if I am implementing it right. And the following confuses me: "According to this specification, a client's request must contain a valid client_id, in the case of a public client". I cannot find an example in the spec on how it expects public clients to send their client_id along with the revocation request. Nor does IndieAuth hint at it
#
aaronpk
let me check...
#
sknebel
hm, that feels odd
#
sknebel
if its not just a general "well we always assume theres a client_id" thing
#
sknebel
but something thats somehow validated
#
sknebel
I'd treat tokens just like private keys for certs: doesnt matter who you are and how you got it, if you have it you can get it revoked
#
aaronpk
i see what you mean
#
aaronpk
oh wait
#
aaronpk
i get it
#
aaronpk
so RFC7009 says:
#
aaronpk
>The client also includes its authentication credentials as described
#
aaronpk
>in Section 2.3. of [RFC6749].
#
aaronpk
and RFC6749 says a public client MUST include its client_id in requests to the token endpoint
#
aaronpk
but yeah i don't see an explicit mention that the client_id needs to be in the revocation request, which seems like an oversight in RFC7009
#
aaronpk
i can ask torsten next time i talk to him :)
#
sknebel
I'd be curious
#
sknebel
especially re validation
#
aaronpk
the notes in the security consideration make sense though, you don't really gain any security by checking for the client_id for public clients since there's way worse things you can do if you are malicious and have the token
#
Zegnat
Exactly what I was thinking
#
sknebel
(i.e. my mental model would be "sure, send the client_id, server might log it etc", but not "require a known client_id to accept a revocation request"
#
Zegnat
I do not feel like I need a client_id to let you revoke, because if you have the token you have access to resources.
#
Zegnat
But the way some of it reads, it seems it only wants me to allow revokes if you know the matching client_id? Which then feels counterintuitive to me
#
Zegnat
Just wanted to get some more eyes on it :)
#
aaronpk
usually these kinds of extra parameters that feel unnecessary at first are there to prevent mixup attacks of various sorts, but there isn't anything to mix up in this spec
#
sknebel
right, to me it is something that if I find a token I should be able to revoke it
#
aaronpk
speaking of which, we should look at the new "iss" spec
#
sknebel
(again parallel to certs: doesnt matter who you are, if you tell a CA "here's the private key for a cert, revoke that!" it has to do so)
#
Zegnat
I would even say the oposite is true for this spec, aaronpk :D If you somehow got a random token that is valid for a private resource, I would lovev it for you to revoke it ;)
#
aaronpk
i need to make a blog post or video that describes the actual risk this is protecting against because it's really confusing
benatkin joined the channel
#
sknebel
do we need to roleplay again?
#
Zegnat
One of these days, that will turn into an actual D&D set
#
sknebel
that reminds me, I found this video snippet about "how the web works" from a German kids TV series again a while back (I can remember seeing the original episode!): https://www.youtube.com/watch?v=fpqhjEtznVk
#
sknebel
that style would be so funny for some explainer videos
#
Zegnat
Reading the iss draft now, those mix-up attacks were what I was thinking of wrt having multiple resources specified when sending a ticket. Trying to trick a client to leak its token to a resource I control. Just could not actually come up with a scenario that would sufficiently trick a client
#
sknebel
this was productive, but I'm off to bed now. o/
#
GWG
sknebel: Sleep well.
#
Zegnat
Same! Was a great grative Create Day everyone, thanks a bunch!