dmitrizagidulin
commented
5 years ago Agreed, we should reverse the order (this was also brought up earlier in this issue https://github.com/solid/oidc-auth-manager/issues/36 and the thread it references).
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.