nodeSolidServer/node-solid-server

Can't access a shared private file on NSS with CSS account

mrkvon opened this issue · 17 comments

mrkvon commented

Possibly related or identical to #1602

Issue

When we

  1. create one fresh account on solidweb.me (CSS v5.0.0) and one account on solidcommunity.net (NSS v5.7.2),
  2. create a turtle file (it's private, you won't see it!) on NSS pod with content 
    @prefix : <https://example.com/>.
:this :is :test.
  3. share the file for reading with the CSS account, so the file's .acl looks as follows 
    @prefix : <#>.
@prefix acl: <http://www.w3.org/ns/auth/acl#>.
@prefix c: </profile/card#>.
@prefix c0: <https://solidweb.me/grouptest1/profile/card#>.

:ControlReadWrite
    a acl:Authorization;
    acl:accessTo <document-person-solidweb-me.ttl>;
    acl:agent c:me;
    acl:mode acl:Control, acl:Read, acl:Write.
:Read
    a acl:Authorization;
    acl:accessTo <document-person-solidweb-me.ttl>;
    acl:agent c0:me;
    acl:mode acl:Read.
  4. try to access the file with the CSS account,

The request fails with 500 Internal Server Error and body normalizedAlgorithm.importKey is not a function

Expected behavior

Person on CSS can access file on NSS pod shared with them

Conclusion

Fixing this would IMO be a big step towards interoperability of the two Solid Pods

See also

context here

The other way around (sharing file on CSS with NSS account) also fails, this time with 401. I've opened CommunitySolidServer/CommunitySolidServer#1441 in CSS repository to report that. That issue got fixed when i added missing solid:oidcIssuer to the NSS test profiles.

bourgeoa commented

Can you give more details :

  • file content type
  • ACL details
  • can you give me your webId's I will add them.

Personally I have no problem with a text.txt file.
There are issues with .img when using mashlib in way of resolving in the next mashlib version

mrkvon commented

@bourgeoa That's interesting that it doesn't reproduce on your side. I tried again and i still get the same error.

Anyways, i updated the OP with the context you asked for.

You can use the CSS webId provided there, to grant access to your .txt. I can also add your CSS webId, if you share it, so you can try accessing my .ttl file.

Here's the cURL of the failing request:

curl 'https://grouptest1.solidcommunity.net/group-test/document-person-solidweb-me.ttl' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0' -H 'Accept: */*' -H 'Accept-Language: en-US,en;q=0.5' -H 'Accept-Encoding: gzip, deflate, br' -H 'Referer: https://grouptest1.solidcommunity.net/group-test/document-person-solidweb-me.ttl' -H 'authorization: DPoP eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCIsImtpZCI6IlJQMlM1V1Q0aHcyWThxaDg5STBwNmIyNnNOamxScHFQcWhnUi1yODdpV2MifQ.eyJ3ZWJpZCI6Imh0dHBzOi8vc29saWR3ZWIubWUvZ3JvdXB0ZXN0MS9wcm9maWxlL2NhcmQjbWUiLCJqdGkiOiJDT1JleHBhWWp5RHptV1FUclNEWXQiLCJzdWIiOiJodHRwczovL3NvbGlkd2ViLm1lL2dyb3VwdGVzdDEvcHJvZmlsZS9jYXJkI21lIiwiaWF0IjoxNjYxNjIxMzYxLCJleHAiOjE2NjE2MjQ5NjEsInNjb3BlIjoid2ViaWQiLCJjbGllbnRfaWQiOiJ2Mk9BQzBWU1dsN05URExNWGxjVnYiLCJpc3MiOiJodHRwczovL3NvbGlkd2ViLm1lLyIsImF1ZCI6InNvbGlkIiwiY25mIjp7ImprdCI6Im4yT0V6VWh0SW5SVFEzRG94bU1nS1JTWlp5d2FJMm9sNklzdFJnUjBxZzQifX0.ruyeiNrwx5QzirlLNhY7r19tvLSP05FM6x6S7gxcwp3RwOX0XtikbJOOlZyq4EYzdmow-IMr8azA_8FEZq5_gw' -H 'dpop: eyJhbGciOiJFUzI1NiIsImp3ayI6eyJjcnYiOiJQLTI1NiIsImt0eSI6IkVDIiwieCI6IjdTVVRLNHJ6Zmp3dUxZa0p4Z1VOREMxTjBUUFJYM2xBUmtZV0xYUzVHejQiLCJ5IjoiczdFTEF4bUJBdzJXYUsxQlRacWRnVVpobTZMd05KNlh2RmJtWjhOTHRHOCIsImFsZyI6IkVTMjU2In0sInR5cCI6ImRwb3Arand0In0.eyJodHUiOiJodHRwczovL2dyb3VwdGVzdDEuc29saWRjb21tdW5pdHkubmV0L2dyb3VwLXRlc3QvZG9jdW1lbnQtcGVyc29uLXNvbGlkd2ViLW1lLnR0bCIsImh0bSI6IkdFVCIsImp0aSI6IjRlNzg1M2JlLTliNjktNGMwNC04NjNiLTVlOTY0Yjg2NmRiMCIsImlhdCI6MTY2MTYyMTM2MX0.Pfy9X7sAsFpOj-Z-6QgDJyWm7hVvIn5Cs_Eds-_MpFcbeDguhY2J_QoMWwEbBhwixvyIBmmss1mQLK8v62NsBQ' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Sec-Fetch-Dest: empty' -H 'Sec-Fetch-Mode: cors' -H 'Sec-Fetch-Site: same-origin' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache'

The auth tokens will most likely be expired by the time you read it, so you won't be able to replay the request, but perhaps it can help with something... 🙂

today i have to go offline. i'll check in again tomorrow afternoon (EEST)

mrkvon commented

Just trying a variation: i get the same error when trying to access non-existent file on NSS while signed in with CSS. So the error imo is on the level of authentication, not authorization (therefore .acl or filetype shouldn't matter).

curl here:

curl 'https://grouptest1.solidcommunity.net/group-test/nonexistent-file.ttl' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0' -H 'Accept: */*' -H 'Accept-Language: en-US,en;q=0.5' -H 'Accept-Encoding: gzip, deflate, br' -H 'Referer: https://grouptest1.solidcommunity.net/group-test/nonexistent-file.ttl' -H 'authorization: DPoP eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCIsImtpZCI6IlJQMlM1V1Q0aHcyWThxaDg5STBwNmIyNnNOamxScHFQcWhnUi1yODdpV2MifQ.eyJ3ZWJpZCI6Imh0dHBzOi8vc29saWR3ZWIubWUvZ3JvdXB0ZXN0MS9wcm9maWxlL2NhcmQjbWUiLCJqdGkiOiI1Q1E2VmhKYmtKQUFvR21OOXVGTEwiLCJzdWIiOiJodHRwczovL3NvbGlkd2ViLm1lL2dyb3VwdGVzdDEvcHJvZmlsZS9jYXJkI21lIiwiaWF0IjoxNjYxNjIyNjI4LCJleHAiOjE2NjE2MjYyMjgsInNjb3BlIjoid2ViaWQiLCJjbGllbnRfaWQiOiJ2Mk9BQzBWU1dsN05URExNWGxjVnYiLCJpc3MiOiJodHRwczovL3NvbGlkd2ViLm1lLyIsImF1ZCI6InNvbGlkIiwiY25mIjp7ImprdCI6ImVmaTAwSkxscDhlUnc1LTdkTjYxaFJxRHBkRDFYQlkzUjh1M1JCZHRiMVkifX0.LBsfpjhFUBXlsPlztOMcCsYOK_UUMUHMd2l-kkKGiZvVPNB7VDPsNMWDz01JZ_wrTRwu-6UFHOcsktXhDzICXw' -H 'dpop: eyJhbGciOiJFUzI1NiIsImp3ayI6eyJjcnYiOiJQLTI1NiIsImt0eSI6IkVDIiwieCI6IkpCeDRfUVhjUWhJRzF1QUR5NTMwSjhmN3QxSmZXR0l1SjJvc29EMjJqdE0iLCJ5IjoiS1VWNmhyc2tEclZxM0NRbUpkVElTcndOd0QtWUxiN3lBaVdJOVlDN3lBUSIsImFsZyI6IkVTMjU2In0sInR5cCI6ImRwb3Arand0In0.eyJodHUiOiJodHRwczovL2dyb3VwdGVzdDEuc29saWRjb21tdW5pdHkubmV0L2dyb3VwLXRlc3Qvbm9uZXhpc3RlbnQtZmlsZS50dGwiLCJodG0iOiJHRVQiLCJqdGkiOiJlZTg0ZGM0Yy1jOWY0LTRiM2MtYmY1Yi0xZDM5NmI3MmYyOGIiLCJpYXQiOjE2NjE2MjI2Mjl9.LgL9FYEQAl53LHzqJhDEG5y3RN8llsO-kQKTNV33QkGA_glSVv2aYBRDj8V6ulo1JA3EaRwE0U-VXuWVEOaBvw' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Sec-Fetch-Dest: empty' -H 'Sec-Fetch-Mode: cors' -H 'Sec-Fetch-Site: same-origin' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache'
bourgeoa commented

@mrkvon I think your issue is with container ACL.
You need Read on https://grouptest1.solidcommunity.net/group-test/ if you have a file ACL.

Adding everybody (or any other valid access) Read in https://grouptest1.solidcommunity.net/group-test/.acl should resolve the issue.

Agree that 500 is not a good error. 401 on CSS seems much better.

Can you confirm ? If OK can you reopen the issue asking for a better error message.

mrkvon commented

@bourgeoa i tried as you suggested, and now the folder's .acl contains

@prefix : <#>.
@prefix acl: <http://www.w3.org/ns/auth/acl#>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix gro: <./>.
@prefix c: </profile/card#>.

:ControlReadWrite
    a acl:Authorization;
    acl:accessTo gro:;
    acl:agent c:me;
    acl:default gro:;
    acl:mode acl:Control, acl:Read, acl:Write.
:Read
    a acl:Authorization;
    acl:accessTo gro:;
    acl:agentClass foaf:Agent;
    acl:default gro:;
    acl:mode acl:Read.

(one can indeed check that the folder is public)

but the issue persists. I can see in my developer console that the browser can fetch the folder now, but it still fails with 500 on the file itself.

I figured it might be helpful to share the payload of my authorization and dpop headers:

  1. authorization: 
    DPoP eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCIsImtpZCI6IlJQMlM1V1Q0aHcyWThxaDg5STBwNmIyNnNOamxScHFQcWhnUi1yODdpV2MifQ.eyJ3ZWJpZCI6Imh0dHBzOi8vc29saWR3ZWIubWUvZ3JvdXB0ZXN0MS9wcm9maWxlL2NhcmQjbWUiLCJqdGkiOiJnVjRvYWprN1JEUjNkVkRmSDNueTgiLCJzdWIiOiJodHRwczovL3NvbGlkd2ViLm1lL2dyb3VwdGVzdDEvcHJvZmlsZS9jYXJkI21lIiwiaWF0IjoxNjYxNzAxMDk1LCJleHAiOjE2NjE3MDQ2OTUsInNjb3BlIjoid2ViaWQiLCJjbGllbnRfaWQiOiJLUFFWRTJObjdwRGtMSEZOYUt2NlIiLCJpc3MiOiJodHRwczovL3NvbGlkd2ViLm1lLyIsImF1ZCI6InNvbGlkIiwiY25mIjp7ImprdCI6ImZIaGFwN01TcGlDaDRLOWIwa3lhcUhqZ0tsX05TRTBPT3JZa2NJdzhyUjgifX0.UFnxm47n_WWUojwFJGmAyxhUSbpbaIo6Zly4aY3kiv4j_Ybh4Bc3zZyWdPRCT904Bia2InWupyN7DIA_PEX8TQ
    and the jwt token decoded has header 
    {
  "alg": "ES256",
  "typ": "at+jwt",
  "kid": "RP2S5WT4hw2Y8qh89I0p6b26sNjlRpqPqhgR-r87iWc"
}
    , and payload 
    {
  "webid": "https://solidweb.me/grouptest1/profile/card#me",
  "jti": "gV4oajk7RDR3dVDfH3ny8",
  "sub": "https://solidweb.me/grouptest1/profile/card#me",
  "iat": 1661701095,
  "exp": 1661704695,
  "scope": "webid",
  "client_id": "KPQVE2Nn7pDkLHFNaKv6R",
  "iss": "https://solidweb.me/",
  "aud": "solid",
  "cnf": {
    "jkt": "fHhap7MSpiCh4K9b0kyaqHjgKl_NSE0OOrYkcIw8rR8"
  }
}
  2. dpop: 
    eyJhbGciOiJFUzI1NiIsImp3ayI6eyJjcnYiOiJQLTI1NiIsImt0eSI6IkVDIiwieCI6InRDdzFxYUpYa3ZlbG5VdTk1V2FVUkNocjFPd3B1MFV6VzdiWmdWdDgtb1UiLCJ5IjoiaElKY0tTc050YnloMVhqeGFucDVRWVNXWjkybWxMQlRxNnRkbjE2dmRTUSIsImFsZyI6IkVTMjU2In0sInR5cCI6ImRwb3Arand0In0.eyJodHUiOiJodHRwczovL2dyb3VwdGVzdDEuc29saWRjb21tdW5pdHkubmV0L2dyb3VwLXRlc3QvZG9jdW1lbnQtcGVyc29uLXNvbGlkd2ViLW1lLnR0bCIsImh0bSI6IkdFVCIsImp0aSI6ImM3YWI5Y2FlLThlNTktNDRmZC1iNTg4LWMxZTA5ZTQ4NGFhMiIsImlhdCI6MTY2MTcwMTA5NX0.XzXzScnbGF1QPPKl53CY9J5L2vmnTqYMCbbrFoZIXN0YaqPWwbs-4mW6TImfamfa4F_tnB7B2c6AGRgBGLRrQw
    which decodes into header 
    {
  "alg": "ES256",
  "jwk": {
    "crv": "P-256",
    "kty": "EC",
    "x": "tCw1qaJXkvelnUu95WaURChr1Owpu0UzW7bZgVt8-oU",
    "y": "hIJcKSsNtbyh1Xjxanp5QYSWZ92mlLBTq6tdn16vdSQ",
    "alg": "ES256"
  },
  "typ": "dpop+jwt"
}
    , and payload 
    {
  "htu": "https://grouptest1.solidcommunity.net/group-test/document-person-solidweb-me.ttl",
  "htm": "GET",
  "jti": "c7ab9cae-8e59-44fd-b588-c1e09e484aa2",
  "iat": 1661701095
}

And let's compare it with sample solidcommunity headers:

Authorization:

DPoP eyJhbGciOiJSUzI1NiIsImtpZCI6IkpxS29zX2J0SHBnIn0.eyJpc3MiOiJodHRwczovL3NvbGlkY29tbXVuaXR5Lm5ldCIsImF1ZCI6InNvbGlkIiwic3ViIjoiaHR0cHM6Ly9ncm91cHRlc3QyLnNvbGlkY29tbXVuaXR5Lm5ldC9wcm9maWxlL2NhcmQjbWUiLCJleHAiOjE2NjI5MTIxMjEsImlhdCI6MTY2MTcwMjUyMSwianRpIjoiOTA4NDQ5MDIxYWFlZTE1OSIsImNuZiI6eyJqa3QiOiJqUUZLQjdDZTVRMG1tbTBIWVdZMDVkNk5seEpsS0ZGYXF0SFR4aEYwelZ3In0sImNsaWVudF9pZCI6ImU3OTY0YTE0YzMzMWE5NjVhMGZhODMzYjJhZmVmYzlmIiwid2ViaWQiOiJodHRwczovL2dyb3VwdGVzdDIuc29saWRjb21tdW5pdHkubmV0L3Byb2ZpbGUvY2FyZCNtZSJ9.QGVpnM87bEh9Ka4iNun9B9hRAzBWCQ6BCbnGcvnyfezfK9MhAzaw6y63aQu2R7k9kxLv4Ow4r-Kna6mPxDQGjEYE2q8UABRL2dXwUaKmhiAJ2vx3J14nOIJ6gGJAcEV3GNLVb1k8W28G7C7KpKhJFHexdwTfMhrRFcjRYU4JAHevXtQteXzQs2tEfCOuVzNxDzlXfo8xpmzNdEUeau1tMdhR_Vd3FOOmEmws19gBBspeGEkwJ9doCVTf6zsZlb5JvKjzoff5ayLzK2zJ9gZiQMyHQsPxnEGKIFQYuhTTqsH998oZr71Y-67J847TWabXv9g-bc8CbA3zpuNcMp5ZJw

jwt header:

{
  "alg": "RS256",
  "kid": "JqKos_btHpg"
}

and payload:

{
  "iss": "https://solidcommunity.net",
  "aud": "solid",
  "sub": "https://grouptest2.solidcommunity.net/profile/card#me",
  "exp": 1662912121,
  "iat": 1661702521,
  "jti": "908449021aaee159",
  "cnf": {
    "jkt": "jQFKB7Ce5Q0mmm0HYWY05d6NlxJlKFFaqtHTxhF0zVw"
  },
  "client_id": "e7964a14c331a965a0fa833b2afefc9f",
  "webid": "https://grouptest2.solidcommunity.net/profile/card#me"
}

dpop:

eyJhbGciOiJFUzI1NiIsImp3ayI6eyJjcnYiOiJQLTI1NiIsImt0eSI6IkVDIiwieCI6ImlFdlpzWHhzT0FxU2xMeWhNanhvLTBzbVNUSGRaVEt5Z2gyT3YwcnM2M3MiLCJ5IjoiYm9NTnM0bWlqR25Kc3BXS2lNNld3ZWV4aEtmdjRDRm5fakg4alM5WDR4NCIsImFsZyI6IkVTMjU2In0sInR5cCI6ImRwb3Arand0In0.eyJodHUiOiJodHRwczovL2dyb3VwdGVzdDEuc29saWRjb21tdW5pdHkubmV0L2dyb3VwLXRlc3QvZG9jdW1lbnQtcGVyc29uLXNvbGlkd2ViLW1lLnR0bCIsImh0bSI6IkdFVCIsImp0aSI6ImJiNDZkOTE2LTY0NTctNDk2OC04YmM0LTgyMzBmZmY3ZTMzNiIsImlhdCI6MTY2MTcwMjUyMX0.gqH6FWvC5BtA4x5B4Qo5YTMGXbRtF2vgjSuXM0C1ULAlYAtMyOwMIHyH92ATMVgoWtQMxfK0T_mvY5yDNMq3Sg

jwt header:

{
  "alg": "ES256",
  "jwk": {
    "crv": "P-256",
    "kty": "EC",
    "x": "iEvZsXxsOAqSlLyhMjxo-0smSTHdZTKygh2Ov0rs63s",
    "y": "boMNs4mijGnJspWKiM6WweexhKfv4CFn_jH8jS9X4x4",
    "alg": "ES256"
  },
  "typ": "dpop+jwt"
}

payload:

{
  "htu": "https://grouptest1.solidcommunity.net/group-test/document-person-solidweb-me.ttl",
  "htm": "GET",
  "jti": "bb46d916-6457-4968-8bc4-8230fff7e336",
  "iat": 1661702521
}

So... i thought the issue was in RS256 vs ES256 algorithms. But the solidcommunity DPoP also says ES256. And that confuses me.

mrkvon commented

Anyways, it's funny that you can make this work @bourgeoa... If you're properly signed out from the owner account, then i'm really confused and don't understand why it works for you and not for me.

If i get time, i may try to debug the NSS code itself. i've never touched NSS code before, so it's a black box for me atm. This would only happen in weeks or months time or something...

bourgeoa commented

I think we need to differentiate group from anything else. Group may be broken ????

mrkvon commented

I think we need to differentiate group from anything else. Group may be broken ????

@bourgeoa what do you mean? Can you elaborate?

The accounts are called grouptest..., and i used them to test how groups work, too. But this issue has imo nothing to do with the groups and with the other tests.
I mean, i can create 2 new accounts and test specifically just this behaviour with them. WDYT?

Or did you mean something else?

mrkvon commented

i can create 2 new accounts and test specifically just this behaviour with them

I just did, and the issue persists.

I placed the file into /public/, but changed the permissions (using standard UI) to

@prefix : <#>.
@prefix acl: <http://www.w3.org/ns/auth/acl#>.
@prefix c: </profile/card#>.
@prefix c0: <https://solidweb.me/interoptest/profile/card#>.

:ControlReadWrite
    a acl:Authorization;
    acl:accessTo <test.ttl>;
    acl:agent c:me;
    acl:mode acl:Control, acl:Read, acl:Write.
:Read
    a acl:Authorization;
    acl:accessTo <test.ttl>;
    acl:agent c0:me;
    acl:mode acl:Read.

I can't help it. At this point, i believe the issue is not on my side. Or i do some obvious mistake.

I believe we could proceed if you @bourgeoa (only if you have time and energy for this):

  • share your testing txt file with one of my testing CSS accounts (https://solidweb.me/interoptest/profile/card#me), or
  • share your webId on solidweb.me (or other CSS instance) with me, so i can add it to my test file permissions, so you can try to access it, or
  • if you share your authorization and dpop JWT token headers (perhaps not the full header, or somebody could do a replay attack on you), so we can do some comparison.

Or if somebody else tries to reproduce this and confirms that the issue is on my side.

Otherwise the next step will be to look into the NSS code. Because i believe normalizedAlgorithm.importKey is not a function actually refers to a bug in the code.

At this point i give up on trying new combinations of permissions, to keep my sanity. 🙂

mrkvon commented

When i ran node solid server locally, this is what came out of logs, when trying to access file with account on solidweb.me

solid:server Error page because of: TypeError: normalizedAlgorithm.importKey is not a function
    at JWA.importKey (/home/michal/dev/solid/node-solid-server/node_modules/@solid/jose/src/jose/JWA.js:90:32)
    at JWK.importKey (/home/michal/dev/solid/node-solid-server/node_modules/@solid/jose/src/jose/JWK.js:31:16)
    at /home/michal/dev/solid/node-solid-server/node_modules/@solid/jose/src/jose/JWKSet.js:32:44
    at Array.map (<anonymous>)
    at JWKSet.importKeys (/home/michal/dev/solid/node-solid-server/node_modules/@solid/jose/src/jose/JWKSet.js:32:29)
    at /home/michal/dev/solid/node-solid-server/node_modules/@solid/oidc-rs/src/ProvidersCache.js:79:28
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) +1s

So i added two console.logs into node_modules/@solid/jose/src/jose/JWA.js around line 90, so it looked rather like this:

  static async importKey (key) {
    console.log(supportedAlgorithms, key.alg);
    let normalizedAlgorithm = supportedAlgorithms.normalize('importKey', key.alg)
    console.log(normalizedAlgorithm)
    return normalizedAlgorithm.importKey(key)
  }

and this came out:

  solid:server Error page because of: TypeError: normalizedAlgorithm.importKey is not a function
    at JWA.importKey (/home/michal/dev/solid/node-solid-server/node_modules/@solid/jose/src/jose/JWA.js:92:32)
    at JWK.importKey (/home/michal/dev/solid/node-solid-server/node_modules/@solid/jose/src/jose/JWK.js:31:16)
    at /home/michal/dev/solid/node-solid-server/node_modules/@solid/jose/src/jose/JWKSet.js:32:44
    at Array.map (<anonymous>)
    at JWKSet.importKeys (/home/michal/dev/solid/node-solid-server/node_modules/@solid/jose/src/jose/JWKSet.js:32:29)
    at /home/michal/dev/solid/node-solid-server/node_modules/@solid/oidc-rs/src/ProvidersCache.js:79:28
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) +1s
SupportedAlgorithms {
  sign: {
    HS256: HMAC { params: [Object] },
    HS384: HMAC { params: [Object] },
    HS512: HMAC { params: [Object] },
    RS256: RSASSA_PKCS1_v1_5 { params: [Object] },
    RS384: RSASSA_PKCS1_v1_5 { params: [Object] },
    RS512: RSASSA_PKCS1_v1_5 { params: [Object] },
    none: None {}
  },
  verify: {
    HS256: HMAC { params: [Object] },
    HS384: HMAC { params: [Object] },
    HS512: HMAC { params: [Object] },
    RS256: RSASSA_PKCS1_v1_5 { params: [Object] },
    RS384: RSASSA_PKCS1_v1_5 { params: [Object] },
    RS512: RSASSA_PKCS1_v1_5 { params: [Object] },
    none: None {}
  },
  encrypt: {},
  decrypt: {},
  importKey: {
    RS256: RSASSA_PKCS1_v1_5 { params: [Object] },
    RS384: RSASSA_PKCS1_v1_5 { params: [Object] },
    RS512: RSASSA_PKCS1_v1_5 { params: [Object] }
  }
} ES256
NotSupportedError: ES256 is not a supported algorithm
    at SupportedAlgorithms.normalize (/home/michal/dev/solid/node-solid-server/node_modules/@solid/jose/src/algorithms/SupportedAlgorithms.js:75:14)
    at JWA.importKey (/home/michal/dev/solid/node-solid-server/node_modules/@solid/jose/src/jose/JWA.js:90:51)
    at JWK.importKey (/home/michal/dev/solid/node-solid-server/node_modules/@solid/jose/src/jose/JWK.js:31:16)
    at /home/michal/dev/solid/node-solid-server/node_modules/@solid/jose/src/jose/JWKSet.js:32:44
    at Array.map (<anonymous>)
    at JWKSet.importKeys (/home/michal/dev/solid/node-solid-server/node_modules/@solid/jose/src/jose/JWKSet.js:32:29)
    at /home/michal/dev/solid/node-solid-server/node_modules/@solid/oidc-rs/src/ProvidersCache.js:79:28
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

revealing that ES256 is not a supported algorithm

So the issue is that NSS uses a library (@solid/jose) that doesn't support algorithm ES256 which solidweb.me uses to sign JWT token in authorization header.

Hope this helps. <3

I opened nodeSolidServer/jose#18 to report that.

Sidenote: Funny, that supportedAlgorithms.normalize('importKey', key.alg) returns NotSupportedError rather than throwing it...

mrkvon commented

Therefore, this is identical to #1602 and could be combined/closed. Funny that @acailly did almost exactly same steps to debug this, and got to the same outcome. I could have read that issue better. 😅

bourgeoa commented

Can you propose a PR.

bourgeoa commented

Does adding an additional algorithm has any consequence on NSS ?
Is it a replacement or just a different check depending on server type ?

mrkvon commented

@bourgeoa Please correct any assumptions below that may be wrong. :)

Does adding an additional algorithm has any consequence on NSS ?

I assume you're asking about nodeSolidServer/jose#19. Funny thing is that NSS doesn't directly depend on @solid/jose, so it may be a bit challenging to propagate the change from @solid/jose to this repository. (first culprit is @solid/oidc-rs according to the error thrown)

solid:server Error page because of: TypeError: normalizedAlgorithm.importKey is not a function
    at JWA.importKey (/home/michal/dev/solid/node-solid-server/node_modules/@solid/jose/src/jose/JWA.js:90:32)
    at JWK.importKey (/home/michal/dev/solid/node-solid-server/node_modules/@solid/jose/src/jose/JWK.js:31:16)
    at /home/michal/dev/solid/node-solid-server/node_modules/@solid/jose/src/jose/JWKSet.js:32:44
    at Array.map (<anonymous>)
    at JWKSet.importKeys (/home/michal/dev/solid/node-solid-server/node_modules/@solid/jose/src/jose/JWKSet.js:32:29)
    at /home/michal/dev/solid/node-solid-server/node_modules/@solid/oidc-rs/src/ProvidersCache.js:79:28
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) +1s

When the change arrives to NSS, it will have the consequence that it will be possible to verify JWT tokens from authorization headers signed with ES256 (currently, at least CSS sends these)

Is it a replacement or just a different check depending on server type ?

It's not a replacement for how NSS signs its authorization headers. Nothing should change there. This will be used to verify JWT token from authorization header arriving from Solid Server implementations that use ES256 to sign the JWT tokens.

Does that answer your questions?

mrkvon commented

Locally, i first need to run npm update (just rm -rf node_modules and npm ci isn't enough), and then the issue is resolved. 🎉

I don't know how you deal with that in this project, but a simple PR with updated package-lock.json could do the trick...

bourgeoa commented

This is very interesting.
Your solution may do the trick but do not update the intermediate dependencies.

If I want to have everything updated I must go through all of them. May be it is not needed . I am not expert.

I published "@solid/oidc-auth-manager": "^0.24.3" and import it in NSS main
Test-server https://solidcommunity.net:8443 is running with the latest main and you can login with CSS accounts and RW on resources.

  • 👍1
  • 🎉1
mrkvon commented

Awesome. Accessing a private resource of solidcommunity.net:8443 works for me both with solidweb.me and inrupt.com accounts 🎉

Your solution may do the trick but do not update the intermediate dependencies.

Right, as far as i understand, if the @solid/jose version is specified with ^ in intermediate dependencies, then npm just installs the latest minor version of it. Unless package-lock prevents it; which we overcame with npm update @solid/jose in #1700

But i suppose that's not needed anymore... Feel free to close :)

Sorry if my previous comments misled you...