Skip to content

Conversation

@jaxoncreed
Copy link
Contributor

No description provided.

.then(providerFromHeaders => providerFromHeaders || discoverFromProfile(webId))

.then(providerUri => {
// drop the path (provider origin only)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really appropriate (I'm just checking here, I honestly have no idea what the 'correct behaviour' should be)? i.e. I know we don't want to strip off any trailing slashes from the origin (i.e. if the URI is https://provider.com/, then we do not want https://provider.com), but do we also want to keep the entire path if there is one (i.e. if the URI was https://provider.com/some/path, do we really want https://provider.com/some/path, or do we actually need https://provider.com/)...? (Regardless, it seems any such logic belongs in the validateProviderUri() function, if indeed we do need any logic to mess around with the providerUri value.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we not want to strip off a trailing slash? I can see that the spec doesn't forbid its presence, but what is the function of keeping it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pmcb55

if the URI was https://provider.com/some/path, do we really want https://provider.com/some/path, or do we actually need https://provider.com/)...?

Yes, we would want it to be https://provider.com/some/path. There is no reason someone would put an extra path in their WebId. We do not want to automagically equate an issuer at https://provider.com/some/path with one at https://provider.com/ as they could be two separate issuers. So I don't think any additional logic is needed.

@michielbdejong

what is the function of keeping it?

This particular section is checking if ISSUER_LISTED_IN_THE_WEBID === ISSUER_IN_THE_TOKEN. Right now, for ESS both the issuer in the webId and the issuer in the token are https://example.com/, but the statement I removed changes the issuer.

Copy link
Member

@michielbdejong michielbdejong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this relate to nodeSolidServer/oidc-rs#10 and https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest ?

Your PR title claims it fixes a problem, but from the fact that you removed some code and inverted a unit test, it seems you it's an undocumented change to the desired behaviour?

Please describe the issue you are fixing here.

To me, it sounds like removing the path (if present) is useful, just like removing an extra trailing slash (if present)?

@michielbdejong
Copy link
Member

michielbdejong commented Nov 24, 2020

if current nss behaviour is wrong because of something we missed, then should the solid test suite also start testing this new requirement?

@jaxoncreed
Copy link
Contributor Author

@michielbdejong While https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest says that any terminating backslash should be removed before adding /.well-known/openid-connect, this section of the code has nothing to do with openid config discovery.

oidc-auth-manager incorrectly assumed that issuers MUST be an origin, when the spec indicates otherwise. https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata indicates that an issuer can be any URL as long as it is "identical to the iss Claim value in ID Tokens issued from this Issuer."

Because the iss claim contains a backslash in the tokens from ESS, the issuer claim listed in the WebId must also contain a backslash. The if statement I removed in this PR messed that up before.

@michielbdejong
Copy link
Member

got it, thanks!

@jaxoncreed jaxoncreed merged commit 0a352c4 into master Nov 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants