Node-solid-server: WebID's from v5.3 server not working to access resource on v5.2.3 server

[michielbdejong]

I can edit https://solidos.solid.community/Team/SolidOs%20team%20chat/index.ttl#this with my
https://michielbdejong.solid.community/profile/card#me webid, but not with myhttps://michielbdejong.inrupt.net/profile/card#me webid (getting a 503)

[bourgeoa]

solid.community his still on NSS 5.2.3
It was not stated that there was a webId compatibility issue with the introduction of an additional new protocol.

[michielbdejong]

I'll update it to >=5.3 soon, that should resolve the issue.

[bourgeoa]

There is a solid.community test server : https:solid.community:8443 running NSS 5.3

[michielbdejong]

ha cool, I wasn't aware of that.
I just volunteered in https://gitter.im/solid/node-solid-server to take over from @jaxoncreed as "primary bug responder" for NSS. We're also tagging a new version of mashlib and once that's done, I'll update the mashlib version in NSS, tag v5.4, and deploy it to solid.community.

[bourgeoa]

@michielbdejong @jaxoncreed
We will test it has soon it is available

We are also waiting to see included :

• PR #1415 related to atomic delete which has been approved some time ago.
• PR #1408 to use node.js LTS in docker in replacement to node.js 8

[michielbdejong]

I'll have a look at both of those, thanks for the heads up.

[bourgeoa]

@michielbdejong
Does that mean that the new token is automatically used by the server under v5.3.0 ?
Then webId's are not anymore compatible with all running servers (NSS or others) if they are not upgraded ?

I don't know the reasons behind the new token. Where can I find information and a discussion on the compatibility/migration problems ?

[michielbdejong]

The new token format is described in https://github.com/solid/authentication-panel/blob/master/oidc-authentication.md. The reason for switching to it is to align webid-oidc more with OAuth2 in general, and that way we benefit more from the security expertise that exists outside the Solid community.

This issue is a bug, and upgrading is a workaround, not a fix or a part of the planned upgrade path. Maybe we can still fix it, and then newer versions of NSS will be compatible with older versions again. But the priority of that depends on how many v5.2 servers will remain by then. We can discuss in our video chat now!

[bourgeoa]

I would like to continue the discussion on this bug, because I feel I do not understand what is happening.

I thought that the premises are :

• webId is a general concept that once you have one it is forever, and returns a token
• this implies that the token is understandable by any webId compatible app and server now and in the future

The consequence should be :

• you don't need to upgrade the server
• if you upgrade the webId provider to introduce new token method, you should be able to send the requested token type
  as requested by the server

I understand that NSS is both a webId provider and a solid-server. So my questions are :

• are these premises true ?
• if not what are the assumptions ?
• if yes
  -- what is actually NSS 5.3 doing ? what should it do ?
  -- what NSS 5.2 do and what should it have done ?

I recently read that in general when using API entry points you should be able to say what version you understand or are using. So you should ask I'm expecting v1 version and be returned a v1 compatible or an error.
Is it the actual philosophy.

[bourgeoa]

I made some tests adding NSS 5.3.0 webId to acl in resources of a NSS 5.2 server.

I do not get a 503 error
I can access the resources with the 5.3.0 webId (Read Write Control) and do read create delete resources

The only point is : there seem to be a very bad performance.

[megoth]

The reduced performance might be related to https://github.com/linkeddata/rdflib.js/issues/419

[bourgeoa]

I made some more tests adding acl:agent to acl rule (so that a rule as more than one acl:agent)

• the performance loss arises allready in https://solid.community running on NSS 5.2.3 (I don't know the rdflib version)
• there is no performance loss if all acl:agent are on the same server

I does not seem to be related to the new token introduced in 5.3.0
I open a new issue