Skip to content
This repository has been archived by the owner on Apr 13, 2022. It is now read-only.

WebID Provider Confirmation Implicit vs Explicit #19

Open
zenomt opened this issue Apr 24, 2019 · 1 comment
Open

WebID Provider Confirmation Implicit vs Explicit #19

zenomt opened this issue Apr 24, 2019 · 1 comment

Comments

@zenomt
Copy link

zenomt commented Apr 24, 2019

the current "The Solution" for WebID Provider Confirmation requires that the domain of the WebID be compared against that of the issuer first ("implicit"), before doing Authorized OIDC Issuer Discovery ("explicit"). i believe these steps should be reversed.

by allowing an issuer's origin to be the same as the WebID's origin (or for the WebID's hostname to be a subdomain of the issuer's hostname), this makes a potentially inappropriate assumption on the operational policies of all domains in the Internet. OIDC issuer URIs don't have to be at the root of an origin (path-abempty == ""). an issuer URI of https://example.com/oidc/ is allowed. the operational policies of some domains might delegate subpaths (/~user/) to ordinary users and allow them to expose programs/APIs there. an origin could potentially host multiple OIDC issuers under different paths and under the control of different users who are not necessarily acting with administrative authority for the entire domain and all of its subdomains, and who should not necessarily have the authority to vouch for any WebID in that origin or its subdomains.

discovery of the Authorized OIDC Issuer for a WebID should be attempted first, and only if a WebID doesn't explicitly state an OIDC issuer can the same-origin or superdomain implicit rule be applied.

this will allow a WebID to be at any URI, and for it to specify any other URI as its issuer, without making assumptions on the operational and access policies of the servers involved.

@dmitrizagidulin
Copy link
Member

Agreed, we should reverse the order (this was also brought up earlier in this issue nodeSolidServer/oidc-auth-manager#36 and the thread it references).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants