Repository: https://github.com/solid/specification - Technical Reports: https://solidproject.org/TR/ - Code of Conduct: https://github.com/solid/specification#code-of-conduct
thats what i get on chrome
I get the same thing on my cell phone with safari
I had to add the explicit @base there as solid-client tried to resolve the turtle nodes with the pre-redirect @ node
So are you creating your own browser, or is it that one needs to be signed into trinpod before any of the pages will resolve to something other than code?
my only thought is...well not the only one... but, if mashlib cant resolve the page...why not?
@dmitrizagidulin how about we transfer solid/identity-panel#1 to solid/specification repo? (Need to unarchive first and then transfer the issue.) I'm not sure if there is going to be enough material or even resources at this time for a whole panel on identity, but that's for participants to decide. If you want to revive, lead it. If in the foreseeable future it is just about having the Solid ecosystem incorporate DID or WebID being compatible with DID, then maybe issue in solid/specification will suffice.
@mikeadams1 the short webid and TrinPod output are now fully compliant: https://frederick.trinpod.us/@ (fixed those pesky periods)
congrats by the way
so the subdomain represents the user
Now live in technicolour: solid/specification#217
we are a pure graph system where each node is an actual graph node - including a node that represents a file or container
I just had a discussion in app-dev about the very important need for apps to be able to trigger a Pod registration flow for new users so that many users won't be lost in the need to click another button on the IDP side to register. The flow for new users being app --> IDP registration (directly - bypassing the generic login page) --> app (logged in with new account) . To make this happen, a simple additional piece of information is needed to send to the IDP, such as landing=registration so that the IDP could go directly to that page
I'm not sure which spec needs to be adjusted to make something like this happen?
I think we should work on it as general on-boarding requirements, I don't think user should just create identity with provider suggested by an app they would like to try out.
While applications should be able to appear and disappear, identity and data should meet higher standard of permanence.
Given that I wouldn't just go with identity and/or storage provider suggested by some app, neither recommend others to do it.
@elf-pavlik I think the simple solution to the issue is that the IDP can decide, given where the request is coming from, to honor going directly to the registration or not. Wouldn't that solve it?
So that there could also be a list of "trusted" apps in the sense that they can be trusted by the IDP to have good intentions with registering new users to that IDP ?
It’s important to mention that not every IdP will allow users to register for accounts. Some IdPs will sit in front of LDAP or ActiveDirectory, which have entirely different user provisioning considerations. Furthermore, even for IdPs that do allow for user registration, there is no standard for doing so.