One question is whether the "OIDC Issuer Discovery" should be "OIDC Issuer Verification" instead?

The current naming is similar to one in https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery

OpenID Provider Issuer Discovery

OpenID Provider Issuer discovery is the process of determining the location of the OpenID Provider.

I changed "WebID Document" to WebID Profile" to align with the WebID draft specification.

In relation to our work on the profile, I would find this extremely misleading. These are the terms we anticipate using :

1, the WebID Document - the document that the WebID dereferences to
2. the Profile Document - the document that contains identifying information about the WebID owner.

Those two may be the same document, but that depends on implementation.

We anticipate adding the following type to the Profile document

solid:ProfileDocument (a more general term than foaf:PersonalProfileDocument)

So in the NSS case, the WebID would dereference to the solid:ProfileDocument and in the ESS case, it would dereference to a WebID document which points to a solid:ProfileDocument with foaf:primaryTopicOf.

Using the term "profile" in conjunction with the WebID document will very much cloud those waters.

If necessary maybe we need solid:WebIDDocument that would be a WerbID Profile Document in the WebID world but in the Solid world would either be the thing that points to the solid:ProfileDocument or NSS would have <>, a solid:WebIDDocument, solid:ProfileDocument.

In relation to our work on the profile, I would find this extremely misleading. These are the terms we anticipate using :

1, the WebID Document - the document that the WebID dereferences to
2. the Profile Document - the document that contains identifying information about the WebID owner.

The WebID draft specification uses the terms: WebID Profile, WebID Profile Document and Profile Document to refer to the resource that a client retrieves after dereferencing a WebID URL.

Note that any resource could contain "identifying information about the WebID owner".

I would suggest using the term "Solid Profile Document" or "Solid Profile". Because WebID is independent of Solid, that would make it possible to define Solid-specific requirements on such a resource.

So I think it best we (in our spec at least) use solid:WebIDDocument to mean a WebID Profile Document which either is also a solid:ProfileDocument or points to a solidProfileDocument with foaf:primaryTopicOf. If it doesn't meet one of those requirements, it might be a WebID Profile Document, but it is not a solid:WebIDDocument.

Well, no because I might have a solid:WebIDDocument that did not point to a profile. Nevermind.

Note that any resource could contain "identifying information about the WebID owner".

But only ones that follow the shape of a solid:ProfileDocument will contain identifying information about the WebID owner that Solid applications can be expected to discover from only knowing the WebID.

w.r.t the rdf:type of the extended/solid profile, I would argue that it doesn't matter. So long as a client "follows its nose" from the WebID Profile, it will find whatever resources it needs to find.

For instance, a client dereferences a WebID and gets an RDF document. The client then follows a particular link and gets another part of the larger RDF graph -- that new part is either in the same Information Resource or it is in another Information Resource (requiring an HTTP GET), but semantically, those two conditions are the same. And as such, it doesn't matter what the rdf:type of that segment of the RDF graph is.

Either way, this is entirely beyond the scope of Solid-OIDC.

The way I see this is like so: you are colloquially referring to a WebID Document and a Profile Document. They may be part of the same Information Resource or spread across multiple such Information Resources -- that is immaterial from the perspective of RDF. If you would like to have language that distinguishes between those two cases, that is fine, but they are equivalent from the perspective of RDF: they are part of the larger information graph.

entirely beyond the scope of Solid-OIDC

Agreed.

they are equivalent from the perspective of RDF: they are part of the larger information graph

True. However different parts of the graph can have recommended shapes. The fact that they are part of a wider graph does not absolve them from having their validity judged individually.

Solid-OIDC will be tagged as FPWD so we still have the possibility to adjust things.

@jeff-zucker If you think we should track it as an issue it would be great if you can create one taking into account what was discussed here. Closed PRs tend not to serve as the best place for discussing possible future changes.

No, sorry, this was thinking out loud. It is not meant to block anything. As @acoburn points out the part I am concerned about is not in scope for the OIDC spec. I'll figure out a way to say what I need to say without contradicting the already established usage.