Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 18 15:03
    @RubenVerborgh banned @michielbdejong
Jeff Zucker
@jeff-zucker
@nickform:matrix.org your question about that section of the protocol would be a good one for the specifications chat, I don't know the answer
Nick Form
@nickform:matrix.org
[m]
@jeff-zucker: I have posted the question there as you suggested.
Joachim Van Herwegen
@joachimvh
the main issue (imo) with the container representation mentioned above is that CSS has 2 representations for the container: the standard LDP representation (with the ldp:contains triples) and whatever is in /index.html if you do a request with a text/html
this is non-spec behavior but something that is in there to make it easier for users to have a nice html page if you go to the root
so can you disable being able to read the root container through acl, but that would then also prevent read access when requesting the text/html option
it ties back to the discussion of what needs to be returned when you do a GET on a container
Joachim Van Herwegen
@joachimvh
CSS can also be configured so the pods are created as subdomains btw
Jeff Zucker
@jeff-zucker
Is there a reason that the size info for foo.ttl is written in foo.ttl.meta instead of .foo.ttl.meta? It would be much more convenient with the preceding dot.
Joachim Van Herwegen
@joachimvh
no real specific reason. I think NSS also used .meta to indicate metadata files? We probably copied that just to make it easier to transfer between the two, unless I'm mistaken
Tim Berners-Lee
@timbl
Here are the logs of a 403 error a user is getting using tibl.com under CSS:
2022-06-27T10:32:59.156Z [BaseHttpServerFactory] info: Received GET request for /timbl/Automation/mother/state.n3
2022-06-27T10:33:00.500Z [DPoPWebIdExtractor] warn: Error verifying WebID via DPoP-bound access token: "iat" claim timestamp check failed (too far in the past)
2022-06-27T10:33:00.511Z [WebAclReader] info: Reading ACL statements from https://timbl.com/timbl/Automation/mother/.acl
2022-06-27T10:33:00.513Z [PermissionBasedAuthorizer] warn: Unauthenticated agent has no read permissions
"DPoP-bound access token: "iat" claim timestamp check failed (too far in the past)"
Joachim Van Herwegen
@joachimvh
that generally means there is an issue with the configuration of the clock on the client's system
Tim Berners-Lee
@timbl
Clients need to to have accurate clocks? How accurate?
So pretty accurate apparently… I guess to prevent replay attacks. @matthieubosquet?
3 replies
Tim Berners-Lee
@timbl
The user in this case says "It is set to UK time so currently shows 12.58pm” .. asking a user to be accurate to 5 secon is a bug
Maybe points to bug in the protcol — just strange that absolute time be a pat of it at all.
Tim Berners-Lee
@timbl
(the user’s time was right, by the way, the same as the time of their message)
Tim Berners-Lee
@timbl
Joachim Van Herwegen
@joachimvh
there were 2 parts to that issue, one being that they used a bad client, the other being the clock which was found out in another issue: https://github.com/CommunitySolidServer/CommunitySolidServer/issues/1014#issuecomment-950796153
the iat claim is part of the openid spec so not something that can just be removed, although I'm not sure how strict the 5s range is, @matthieubosquet would know
Tim Berners-Lee
@timbl
For the @jessegeens syncng their laptop with NTP worked. (a) It s unreasonabe tp expect real users to have to do that. (b) we have sill a problem
I’ll try patching it to 500
Tim Berners-Lee
@timbl
Its running now. Not everyone has tried it. Only thing I noticed in the logs was:
2022-06-27T18:25:28.001Z [WrappedExpiringReadWriteLocker] error: Lock expired after 3000ms on https://timbl.com/[...]
2022-06-27T18:25:28.006Z [StreamUtil] warn: Piped stream errored with Lock expired after 3000ms on https://timbl.com/[...]
2022-06-27T18:25:28.006Z [BasicResponseWriter] error: Writing to HttpResponse failed with message Lock expired after 3000ms on https://timbl.com/[...]
2022-06-27T18:25:29.008Z [GuardedStream] error: No error listener was attached but error was thrown: aborted
Joachim Van Herwegen
@joachimvh
That sounds like a request didn't read out the stream it got from the server (or did it too slow) causing the read lock to expire
Tim Berners-Lee
@timbl
This is a resource which is patched quite often. Does the patch lock it for longerI wonder.
Joachim Van Herwegen
@joachimvh
depends on how big it is, as for patching we have to load it entirely in memory to do the modifications
Tim Berners-Lee
@timbl
Richard says, “.I use a PC which is set to UK time. The mac is also on UK time (easier for me to have it on UK time as the diaries I work with are primarily UK). The tracker is still not opening - same message as yesterday. Have closed the browser and tried in Edge browser. Just looking to see if I have firefox or safari"
I wonder whether the fact that his machine is set to the wrong tz in fact could make a diff ..the code accesses the wrong form of time of something
Matthieu Bosquet
@matthieubosquet

Validating the iat claim with a five seconds margin comes off this recommendation:

If an adversary is able to get hold of a DPoP proof JWT, the
adversary could replay that token at the same endpoint (the HTTP
endpoint and method are enforced via the respective claims in the
JWTs). To prevent this, servers MUST only accept DPoP proofs for a
limited time window after their iat time, preferably only for a
relatively brief period (on the order of a few seconds).

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-04#section-10.1

It has been relaxed in the latest DPoP draft:

(preferably only for a relatively brief period on the order of seconds or minutes)
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-09#section-11.1

So I guess maybe increasing it to 2 minutes could be an agreeable compromise?
Joachim Van Herwegen
@joachimvh
you're the expert here so I'll leave it up to you :D
but that sounds fine
Matthieu Bosquet
@matthieubosquet
Hahaha, I just read the spec ^^, I don't know if that makes me an expert lol.
But I think it's fine to relax the DPoP proof to 2 minutes max age.
PR: https://github.com/CommunitySolidServer/access-token-verifier/pull/173/
Tim Berners-Lee
@timbl
The fact that this relies on the client having a very accurate clock seems to be a bug — can’t one be clear that the dPop message is fresh without comaring a time from the client with a time from the server? Is that the problem?
It would be good to run tests with client clocks set to a completely date!
I don’t understand the dPop or OIDC in detail, that’s just a meta-requirement.
Matthieu Bosquet
@matthieubosquet

As far as I understand, the requirement for DPoP proofs became evident mostly because of mobile devices (secure access token usage is more challenging there).
But Solid OIDC doesn't require the DPoP binding of access tokens.

For example, from the access-token-verifier's perspective, Access Tokens can be 24 hours old by default.
It seems that DPoP binding is becoming more widely accepted as good security practice beyond mobile devices, but I don't think that more lenient methods will disappear overnight.
In other words, DPoP is just one of many attempts at improving the security of Bearer tokens, but a client that lacks confidence in its clock (which sounds like a very edge case after increasing the lenience to the order of several minutes) could very much just use a simple Bearer Access Token (not DPoP bound).

I don't think that it is advisable to not use DPoP though. Hopefully a lenience of 2 minutes is enough and potentially one might increase it to slightly more if empirical evidence shows it is a strong need.


For the sake of completeness in the matter:

  1. The iat claim in DPoP tokens is used to prevent replay attacks.
  2. Preventing replay attacks is also ensured via the jti claim (a unique identifier).

Therefore, the balance to strike is between the size of the jti index and the age of tokens. In other words, if I keep a list of all jtis of tokens used in the last 2 minutes, I'm fine to say that DPoP tokens can be at most 2 minutes old, but that has a cost and becomes also more challenging when a system is distributed and so on (in other words, the default JTI cache and settings of the access-token-verifier have been designed to accomodate most use cases at a low cost in terms of infrastructure and setup).

elf Pavlik
@elf-pavlik

But Solid OIDC doesn't require the DPoP binding of access tokens.

Current version of Solid-OIDC relies on binding ID token not Access Token, the later is issued by AS associated with RS and can't be used elsewhere

In Solid making ID Token sender constrained (by binding it to client's public key) is very important. Without it, the client could use that ID Token with AS associated with a malicious RS. When the token is not sender constrained that malicious AS+RS could start using that token and authenticating as a user with other RSs.
By making ID Token sender constrained, they can't do it since presenting token is not enough, the party acting as the client needs to prove that the token was issued for them, Solid-OIDC chooses DPoP as the proof of possession mechanism.

BTW GNAP chooses to support different proof-of-possession mechanisms https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-09.html#section-7.3
Tim Berners-Lee
@timbl
When I go back to a webapp which has been logged in for a while, I get 401 errors …as though the dpop refresh isn’t working.
2022-07-01T09:47:25.319Z [BaseHttpServerFactory] info: Received GET request for /timbl/[…]ttl
2022-07-01T09:47:26.592Z [DPoPWebIdExtractor] warn: Error verifying WebID via DPoP-bound access token: "iat" claim timestamp check failed (too far in the past)
2022-07-01T09:47:26.606Z [PermissionBasedAuthorizer] warn: Unauthenticated agent has no read permissions
Tim Berners-Lee
@timbl
It could be a problem with the client library
Emelia Smith
@ThisIsMissEm
Is it possible to start a CSS instance with user accounts and credentials pre-provisioned?
Matthias Evering
@ewingson
solidweb.org and solidweb.me will both go down for est. 10 min to renew certs
Matthias Evering
@ewingson
solidweb.org and solidweb.me both up and running again