Issuer Discovery from Link Header vs WebID Profile

[zenomt]

when using the "Issuer Discovery From Link Header" method, the issuer is linked to the PersonalProfileDocument, not to the Person inside that the issuer is actually vouching for. in other words, the subject of the link isn't the WebID. i don't think that's semantically right.

doing an HTTP OPTIONS on the location of the profile document takes at least one extra round-trip time (assuming you'll retrieve the full document eventually anyway and so will already be establishing a TLS+HTTP connection to the server) in order to potentially get not-really-right information. furthermore, ordinary web servers (on which it should totally be fine to host a profile document) are unlikely to provide this link relation in an OPTIONS call.

therefore, the first (and probably only) choice should be the one described in "Issuer Discovery From WebID Profile". the semantics are clean and correct, the functionality can be supported by any web server, and an unnecessary HTTP transaction and its round trip time are saved.

i propose striking the entire "Issuer Discovery From Link Header" subsection.

[dmitrizagidulin]

While I don't object to removing Issuer Discovery From Link Header section if it's not useful, I do want to clarify:

the issuer is linked to the PersonalProfileDocument, not to the Person inside that the issuer is actually vouching for

I think you misunderstand. This method is to discover the authorized URL of the server, for a given WebID Profile document (not the person).
Meaning, that if I have somebody's WebID, like https://dz.solid.community/profile/card#me, I can do an OPTIONS request and figure out which OIDC Provider is authorized, for that profile. For example:

curl -v -XOPTIONS https://dz.solid.community/profile/card

> OPTIONS /profile/card HTTP/1.1
> Host: dz.solid.community

< Link: <https://solid.community>; rel="http://openid.net/specs/connect/1.0/issuer"

So, this has nothing to do with semantics for a person.

[zenomt]

i mean that the OPTIONS request is on /profile/card, and the returned Link for an OIDC issuer would be for /profile/card, but the webid of interest is /profile/card#me. that only makes sense if the semantics of rel="http://openid.net/specs/connect/1.0/issuer" means "issuer for the foaf:primaryTopic of URI", which seems hacky.

[zenomt]

to put it a slightly different way: the first step in "Issuer Discovery From Link Header" says "1. Make an HTTP OPTION [sic] request to the WebID URI." but that's not actually possible, because the WebID URI typically includes a fragment identifier, but fragment identifiers are not sent to HTTP servers as part of the request URI.

any links in a Link header returned by the server refer to the requested URI, but here the requested URI is not the WebID, rather it's the profile document that contains the WebID. the OIDC issuer doesn't issue profile documents; it issues WebIDs.

for this use case, the information returned in the Link rel="http://openid.net/specs/connect/1.0/issuer", while it could have some meaning, isn't relevant to discovering the issuer of the WebID itself (the WebID URI isn't the subject of the implied triple). at best it's a non-sequitur, at worst it's erroneous (a claim that's not true).

additionally, for the server to even want to give that Link in its response, there has to be something magical about the profile document that the server knows (some kind of metadata or other special knowledge that this is a profile document and what its issuer is, perhaps transformed by the server from the http://www.w3.org/ns/solid/terms#oidcIssuer claim inside the profile). expecting this above-and-beyond behavior from an HTTP server isn't reasonable or necessary when there's a more direct, fits-with-the-simple-web way to get the same information, that all web servers already implement (that is, returning the requested document).

[dmitrizagidulin]

@zenomt thanks!

I'm +1 on deprecating the "Issuer Discovery From Link Header" method. I don't think it's used out there in the wild (the auth clients are using the other method).

What do the rest of the Solid folks think?

[elf-pavlik]

@dmitrizagidulin maybe worth marking it at risk with link to this issue? People could voice their objections (if any) directly on your PR.

[dmitrizagidulin]

@elf-pavlik sounds good!

[jvasseur]

I see one valid use case for discovering issuer with link headers: if you put the link header on the whole domain this allow users to connect by filling only their domain during provider selection instead of the full webId.

The workflow would be the following:

• User enter only the domain part during provider selection
• App fetch link header and redirect to auth URI
• User login with login and password
• User get redirected back to app with token containing webId

[nickform]

Does anyone know the status of this? According to @dmitrizagidulin's update from 24 Apr 2019, the method marked at risk is not used in the wild but experimenting with my own profile today (https://nickform.inrupt.net/profile/card#me) I find that only that method is available - i.e. my profile document does not contain a triple using the http://openid.net/specs/connect/1.0/issuer relation. I'm just a curious passer-by trying to understand authentication in Solid.

[acoburn]

Much of the current work related to authentication in Solid is being conducted in the context of the Authentication Panel, and the current draft specification will have the most up-to-date information about what is and what isn't in scope for authentication in Solid.

As to your question about this particular link header, it is not part of the current draft specification. Your profile document also does not contain the triple <#me> solid:oidcIssuer <trusted-issuer-URL>., which is required by the current draft. Node Solid Server supports the profile format you have in place because it relies on the fact that your Pod is part of the same domain (inrupt.net) as the identity provider, which has been allowed in the past but which is not part of the current specification.

[nickform]

Thanks for the explanation @acoburn .