Zegnat!tell GWG I see a bunch of redeemed tickets ~2 hours ago? Did you get everything working now? Cool! Will add something to my site today that only exists when a token is provided.
ZegnatAnyone else doing that yet? Any examples of how people do it? I was thinking of adding Token Introspection for that at some point, but that is a little further down my list
ZegnatThe reason I set resource as the root domain is actually a hack. My token endpoint basically forgets about resource immediately as that is not really a thing in base indieauth. So as my data structure is right now, I cannot return it.
ZegnatI am also not sure I like the name resource for it. Especially if it may grant access to all underlying URLs too. As mentioned in one of the open questions.
ZegnatIt does show the expires_in ... I should really consider adding that. Do you expect expires_in only when exchanging the code for the token, or even when doing a verification call?
ZegnatI do not think OAuth uses it. But I wonder if that is just because OAuth works with the assumption that you as the owner of a token already knows where it is accepted.
Zegnataud would be a list of resources where the token is expected to be accepted. So if the current page is in the list, that is the token you can send.
ZegnatI wonder, is this even a use-case we need? If we focus on authentication, we do not need it, right? You can use the token that identifies you as you on any resource that has its token_endpoint set to where you got your token from.
ZegnatIf we both trust the same token_endpoint, then GWG only needs to get a ticket once from there to proof he is who he is. We would both accept the token.
ZegnatI am thinking of the Gemini case a little. Where people can send a cert along with each request to say “this is me”. If I have obtained an authentication token from tokens.indieauth.com (through a ticket or other means) that has a me value of "https://vanderven.se/martijn/", I can start sending that token along to every site I know that has tokens.indieauth.com as their token_endpoint. They trust that token provider, so they can
sknebelZegnat: no, you cant do it cross-domain, because otherwise I can just claim to trust e.g. davids token endpoint and then I get a valid token for you that I can use to read stuff as you
ZegnatYou should check, I guess, to make sure you do not send the token someplace someone else can read it, else you get the imposter attack you mentioned above.
ZegnatIf you are not checking first, it means you are making the call based on something else whether to send the token. Then that "something else" should be == realm
ZegnatTo be fair, this is also a problem with realm. You do not know a resource realm without first requesting the resource and reading its WWW-Authenticate header.
sknebelright. on a domain the imposter case is less obvious/common, so for our purposes it might be ok to not cover that (basically, if you combine it with path limits you say that you can't have less trusted things on subpaths of a URL. which is likely true for most personal sites, and can be made ok for many but not all other scenarios)
ZegnatHTTP Signatures has me sign the request path and host header. So even if I were to send a request to a wrong entity, they can never use it to impersonate me against another party.
ZegnatIf we have a shared secret, and I use HTTP Signatures, if I send a signed request to sharedhost.test/~someoneelse/controls/this the someone else cannot grab the value and start impersonating me against other sites on sharedhost. Because only you and I have the shared secret
jamietannaGWG I wonder if the token issuing is the wrong place for the `resource` and it should instead be on verify - I'll do some reading to confirm that against how OAuth expects it
jamietannaI'd say if we can try and keep it closer to OAuth2 that may make it simpler - my ideal would be that we replace the IndieAuth-only endpoint with the OAuth2 one, as then we can use libraries out-of-the-box (but I realise we've done it this way as it's much simpler)
ZegnatNobody expects anything from token verification. IIRC that is something that only exists in IndieAuth. (Then again, it does not define any form of expiration/expires_in/exp...)
jamietannaThat sounds good - we should definitely provide folks with understanding of how to respond to a token that's no longer active (revoked/expired)
ZegnatThere are only unique things if we want data to be made available upon token verification. Because I think that is the only IndieAuth specific part?
ZegnatThe resource one ... I am still not sure exactly how to scope this stuff. So that might be a bit early? Also sounds like something for the ticket auth extension and not indieauth proper? Maybe?
aaronpkIIRC the idea with "realm" was to use it for scoping access within one resource, so you could use it for indicating like which group of friends something is accessible to
Zegnatroot URI + realm = protection space. So different resources on the some domain can share realm to communicate that the user can use the same auth for all of them.
jamieInteresting - would that be on the response for redeeming the ticket? `aud` to me would be the audience for the token i.e. `client_id` usually, or `subject` in the case of how we issue the ticket
LoqiGWG: Zegnat left you a message 1 minute ago: Any future tokens you request through a ticket from me should now have expires_in. Let me know if it looks right.
@dshanskeAfter declaring my intention to help iterate on the Ticket extension to IndieAuth, I built an experimental ticket endpoint, which is available on my test site. I was able to test it using Martijn van Der Ven’s test form for requesting a ticket., after… https://di5.us/t/1Qr (twitter.com/_/status/1412129563539279874)
[fluffy]yeah, I was going to have Publ initiate the grant if someone logs in with a profile that declares an endpoint, and there’s no reason there can’t also be a manual login flow for that
[fluffy]…although I suppose that means Publ itself is going to have to be able to parse out the endpoint too. So maybe it should all be up to Publ to do that, instead of adding the endpoint discovery to Authl.
Loqilife happens is a summary expression of numerous things that people experience in their actual physical lives that suddenly take higher priority than nearly anything else (like participation in volunteer-based communities), and the IndieWeb community is here to acknowledge, accept, and be supportive of community members experiencing this https://indieweb.org/life_happens
Zegnat https://indieweb.org/IndieAuth_Ticket_Auth#Martijn_van_der_Ven - documented the endpoint as you seem to be able to use it. So others can test against it aswell if they are interested
GWG It might be citing prior work at https://www.rfc-editor.org/rfc/rfc8707.html
sknebel right. on a domain the imposter case is less obvious/common, so for our purposes it might be ok to not cover that (basically, if you combine it with path limits you say that you can't have less trusted things on subpaths of a URL. which is likely true for most personal sites, and can be made ok for many but not all other scenarios)
jamietanna Zegnat I also use `expires_in` as I'm another implementer with expiring tokens
@dshanske After declaring my intention to help iterate on the Ticket extension to IndieAuth, I built an experimental ticket endpoint, which is available on my test site. I was able to test it using Martijn van Der Ven’s test form for requesting a ticket., after… https://di5.us/t/1Qr (twitter.com/_/status/1412129563539279874)
@jmartsch ↩️ You could also use Webmentions, an open standard for a protocol to notify about links, likes or comments to a webpage. Here is an article describing it https://daily-dev-tips.com/posts/goodbye-comments-welcome-webmentions-%F0%9F%99%8B%F0%9F%8F%BC%E2%80%8D%E2%99%82%EF%B8%8F/ (twitter.com/_/status/1412155610007810050)
[fluffy] also not sure how quickly I’ll be able to work on it, I’m experiencing some /life-happens lately.
Loqi life happens is a summary expression of numerous things that people experience in their actual physical lives that suddenly take higher priority than nearly anything else (like participation in volunteer-based communities), and the IndieWeb community is here to acknowledge, accept, and be supportive of community members experiencing this https://indieweb.org/life_happens