Is there any guide written in informal words by someone who used the draft?
Besides TS implementation I also wrote this short primer: Solid Application Interoperability - Application Primer
How does an app discover, whether a person ( Social Agent ) has anything relevant for it in their POD?
The application should publish their Access Needs which will be used during the authorization flow. If the user grants this application required access Application Registration will be created for that application and it will be following their nose from there.
How to create a new resource that app could use to store its data
The app should use shape trees from some common place, we consider putting one out in the interop panel. Having that user would use their Authorization Agent to create Data Registration (max one per storage their own) which than they can authorize an app to access.
and optionally share it with other people (or groups of people) or applications?
Users own their data so only users can share it with other users. Users use applications to access data they authorized it to access, but the application being just a tool and not owning any data can’t really share it.
I don’t understand where the app’s identity profile document is supposed to live, and how it relates to the actual web or mobile app. I’d like to be able to advertise to people Check this Cool App at https://check.this.cool.app.example/, not https://check.this.cool.app.example/#id. I want them to see some action, not a profile document. And i hope apps can still remain serverless (i.e. hosted on github pages). Again, an example or an informal explanation would go a long way.
Solid-OIDC also introduces a public app profile document. Currently, we only looked there into verifying app identity based on the redirect url in that profile. We definitely need to address how app identity can be verified for mobile apps. So far we discussed using client credentials flow where each user can create themselves static registration for app they are using.
I don’t think there should be any problem with static hosting, apps could be hosted on github pages or even better in solid storage.
I would think that it would be a best practice for either servers or pod providers to provision pods with the basic profile and settings locations already set up with needed permissions (e.g. append but not write).
In interop spec we have the very important role of User’s Authorization Agent, we can see it as something similar to Identity Provider. I would expect that deployments would commonly combine those two. As a party fully trusted by their user (just as the IdP) it will be able to assist user in tasks that regular applications should not be involved in.
everyone invents their own approach until the discovery spec is done
Implementing TS library to be used by applications helped us improve current draft quite a bit. By the rest of this year I will implement module to be used by Authorization Agent which will help us improve remaining bits. I know that @justin will follow with Java implementations. SAI should be pretty stable by the end of this year.
Just to give some perspective, in AuthN panel we are still considering some breaking changes to Solid-OIDC and AuthZ panel seems to be moving pretty slowly for quite some time. I would be surprised if interop spec was the one holding developers back.