acoburn
commented
3 years ago the exp claim that appears both in the DPoP-bound Access Token and the OIDC ID Token
Aside: there is no exp claim that is part of the DPoP specification, so we should remove any references to that. exp claims just apply to the access token.
but in point 7., if the public key hasn't changed, then perhaps it doesn't need to validate the signature
it would be problematic to not validate the signature. For instance, if I provide one access token with kid: "foo" that is validated successfully and then provide a false access token in the next request (one which claims to be some different user), then I could easily impersonate someone else. This also works the other way: if I know that some user is actively using Solid (e.g. because I see activity in a chat), I could look up their WebID and find the name of the public key in use by their authorized oidcIssuer. Taking those values, I could then craft an invalid token that appears to use the same key and claims to use the same WebID. It would be harder to do with with the thumbprint of the DPoP key, but a malicious server that has some insight into user activity could mount that sort of spoofing attack.
Do you see more opportunity for using conditional requests in the basic flow?
There are plenty of opportunities for this. First, when a resource server fetches a WebID, that data could certainly be cached: there are various ways to do this that are more or less sophisticated: one can simply cache the oidcIssuer values locally for a fixed period of time, or one can cache these locally and use conditional requests to re-validate the data on each token validation, or one can revalidate only if the cached oidcIssuer values don't match the incoming iss claim. (I generally would prefer to avoid HTTP round trips if this data is "fresh")
A resource server will likely also want to cache the public JSON Key Sets (JWKS) from the issuing identity providers. A pattern that I've seen in several places for this is the following:
- if the JWKS is not in the local cache at all, fetch it
- if the JWKS is in the local cache and the
kidandalgin the access token matches thekidandalgof one of the keys, use that key - if the JWKS is in the local cache and the
kidandalgin the access token don't match any of the cached keys, attempt to re-fetch the JWKS
kjetilk
I have read the Solid-OIDC draft, and it was very readable, thank you for that!
My initial thought was the the general flow requires quite a lot of connections, and that we should look into optimizations. Since I'm more than average interested in caching as an approach, I started thinking what we could do on the protocol level for this.
AFAICS, Solid-OIDC does not make normative statements that ties it to HTTP, which is good, so this would also not belong in the Solid-OIDC document, but I'd like to air it.
There seems to be two types things that it seems could bear fruit in the short term:
One is the
expclaim that appears both in the DPoP-bound Access Token and the OIDC ID Token. That seems to map well to aCache-Control: max-ageheader in HTTP, so that it can be cached by normal HTTP caches in various positions on the Internet.The other seems to be using conditional requests to see if it is possible to jump out of the flow in certain places. It seems harder though, but in point 7., if the public key hasn't changed, then perhaps it doesn't need to validate the signature. That's not a big saving, I guess. Do you see more opportunity for using conditional requests in the basic flow?