node-solid-server
node-solid-server copied to clipboard
nodeSolidServer
Add `solid:oidcIssuer` link in profile template
https://github.com/solid/node-solid-server/blob/master/default-templates/new-account/profile/card%24.ttl
has no triple for solid:oidcIssuer.
This is because we expect the client to optimistically assume that if https://xyz.abc/foo/bar#me describes a human being, then https://xyz.abc may be usable as a trusted OIDC issuer for webid-oidc for that person.
But then the client has to retrieve https://xyz.abc/.well-known/openid-configuration, see if all the right token types, flows, etcetera are announced, and that requires a simple addressbook app to know a lot about how webid-oidc works in detail.
For instance, currently https://michielbdejong.solidcommunity.net/.well-known/openid-configuration announces "token_types_supported":["legacyPop","dpop"] so that's a strong hint that it may be a webid-oidc provider. But the only way for the client to know is to try.
When adding WebID's to an ACL document, the client will have no way to try out logging in as that user. It would be much easier if the profile document states whether or not its domain root is a webid-oidc-capable IDP.
Addressbook apps should not need to understand the details of how webid-oidc works, and should not need to change their business logic when the details of webid-oidc evolve.
So we may want to separate those concerns and let the profile card announce explicitly when this is true, so that clients have to do less leg work and get less false positives when trying to list which contacts have webid-oidc-capable WebID's.
The solid:oidcIssuer field in WebIDs is now mandatory per https://solid.github.io/solid-oidc/#webid-profile (related to #1639 )
The solid:oidcIssuer field in WebIDs is now mandatory per https://solid.github.io/solid-oidc/#webid-profile (related to https://github.com/solid/node-solid-server/issues/1639 )
Thanks. It will be added. This is a very recent draft specification . Adding in profile template is not enough. There is a migration to dao. Needs to be added to all pods. Some used in relation with CSS have already solid:oidcIssuer.
There is also a group working webId document and profile Document recommendation.
I am in favor of adding the solid:oidcIssuer to NSS WebID documents. However, this raises the security issue that any app with write perms on the WebID document could overwrite the oidcIssuer and thus hijack the entire pod. ESS handles this by keeping the WebID document separate from the user-editable foaf:primaryTopicOf document. And alternate approach would be for NSS to intercept all writes to the WebID document and forbid those which attempt to change the oidcIssuer. There could be an alternate route (e.g. email) for users to request changes.
As an alternate route and with the same idea that we have an owner stored in podRoot/.meta we could also reference oidcIssuer there and check any change in profile document against it.
What's to prevent the same app that writes to the profile from also writing to the podRoot/.meta?
And I might have several storages which might not even be on the same host.
Anyone with access to podRoot/.meta has full access to changing owner and taking control of the pod. Never give the key of your safe.
Well, I would argue that is a reason the server should prevent changes to the oidcIssuer in both the podtRoot/.meta and the profile.
I suppose it could be easily solved if the podRoot/.meta were a http://www.w3.org/ns/solid/terms#servermanaged resource (see metadata spec).
How do you change servermanaged resource ? They can only have Read access.
My suggestion (which might not make sense, and I am not strongly attached to), is that the server be the only thing that can change the oidcIssuer, So, Write access is not required there.
I'd suggest taking the approach of ESS here, though do keep an eye on what the WebID Profiles WG is working on: https://github.com/solid/webid-profile
There's some questioning whether foaf:isPrimaryTopicOf is the right predicate to use for the user-editable profile documents (instead of say, owl:sameAs)
Making the WebID only editable by a limited number of Applications does make sense, e.g., you don't want an application to add a new pim:storage predicate to your WebID when you've not actually wanted that.
I'm currently working on an application where I'll allow users to login with the WebID IRI, such that they do not need to remember who their OIDC issuer is and what that URL is — one URL that they share with people and use to login in is far simpler. Plus solid:oidcIssuer can support multiple values, so you could log in to one WebID from multiple OP issuers, in theory.
@ThisIsMissEm - I will get a chance, it appears, to discuss this with you further next Tuesday at the WebID-Profile WG. Let me just say that I am delighted that you are reconsidering the use of foaf:primaryTopicOf and I have some specific suggestions about what you could use instead that would both solve Inrupt's goal of separating the IdP portion of the profile from the user controlled portion while at the same time being compatible with the process used on NSS, SolidOS, and the majority of current apps. If you'd like to discuss before Tuesday, please feel free to ping me in one of the gitter chat rooms.
@jeff-zucker It's not that ESS or Inrupt is reconsidering it, I think I was a little ambiguous there: I have seen a few conversations and different people questioning the use of foaf:primaryTopicOf and all that I'd say there is that just because ESS used it for now, if it really wasn't most appropriate, then the spec could say something different.
e.g., WebID Profiles group could say "actually, foaf:primaryTopicOf shouldn't be used, owl:sameAs or owl:seeAlso are actually more correct" and it'd be up to ESS to argue why foaf:primaryTopicOf is more appropriate; As such, I'd definitely recommend inviting someone from the ESS team at Inrupt to the meeting where you discuss foaf:primaryTopicOf
(aside: in our SDK we semi-often need to patch over differences like that, in order to support different versions of ESS and other servers).
no need to implement for external webid in account creation lib/models/account-manager.js External WebId was removed from account creation https://github.com/solid/node-solid-server/pull/1566
I am not sure what you are saying there @bourgeoa. If I list multiple oidcIssuers in my profile (which is perfectly fine in the spec and needed in some situations), that provides apps with the ability to login in different places for the user. It does not allow someone to use an external WebID to access the pod - that is a server decision.
implemented in default profile at account creation https://github.com/solid/node-solid-server/pull/1673
I am not sure what you are saying there @bourgeoa. If I list multiple oidcIssuers in my profile (which is perfectly fine in the spec and needed in some situations), that provides apps with the ability to login in different places for the user. It does not allow someone to use an external WebID to access the pod - that is a server decision.
@jeff-zucker It was just a comment for future reminder. NSS do not actually allow for account creation with external WebId. It was removed for security reasons. That's why I did not try to implement the functionality for finding the oidcIssuer in that specific case.