[tb]That's kind of what I was thinking — my IndieAuth token endpoint actually generates JWTs today so I can use them from other services of mine. I was thinking it might be good to start putting the `aud` claim in them, and so perhaps for each scope I just have a mapping of URLs that would be added to that claim
ZegnatSure. But also note that if your Micropub endpoint is somewhat integrated with your IndieAuth solution, you do not actually need it to use create/post/... at all. Your IndieAuth provider could translate create into create:private create:public create:group create:dm whatever. And put those scopes on the token instead of create.
ZegnatLots of possibilities. You could also just have separate UI in your IndieAuth flow where you can select audience values to assign. Even if they were not specifically requested by the application
GWGaaronpk: If you look at the W3C version of the spec, it says to verify an authorization code, which is the previous post option to the authorization endpoint, section 5.4 of the W3C edition, you only needed code, client_id, and redirect_uri
GWGI'm going over every part of the flow as I make these changes. This time, I'm adding comments to the code to remind myself in future what I was trying to do
ZegnatI would probably issue a token even with just profile. I guess it would enable someone to refetch the profile information using the token instead of having to request a code exchange anew.
ZegnatI think the only take-away from the spec is that scope is optional because sometimes people just want to validate once. And when scope was empty in the first request, you should not issue them a token at all. But that is it. So before the code exchange step you should not really care about whether scope is empty or filled in
[tb] Actually did want to bring this over here now that I brought it up [Zegnat]
Zegnat Sure. But also note that if your Micropub endpoint is somewhat integrated with your IndieAuth solution, you do not actually need it to use create/post/... at all. Your IndieAuth provider could translate create into create:private create:public create:group create:dm whatever. And put those scopes on the token instead of create.