Either of these suggested changes would work for me.

(It may be worth a reminder that this document is still an Editor's Draft of a CG Report; it's not anything from a WG, nor even a "final" CG Report. It may be time to consider reviving the WebID CG, or even drafting a charter for a WebID WG.)

We need to think how this fits together with DIDs. When is their review finished? https://www.w3.org/TR/did-core/ ?

@bblfish -- I think WebIDs are almost if not entirely orthogonal to DID Core, which I believe is to exit CR by the end of July, with PR by end of September. @burnburn, @brentzundel, @msporny, or @iherman -- please comment, correct, or confirm.

yes, so it would be good to bring our experience of WebIDs to bear upon DIDs before it exits CR.

@bblfish -- I sincerely hope you are not suggesting that you're going to want normative changes made to DID Core during this second CR, by a WG whose charter expires in September. It would have been better to bring your experience of WebIDs to bear upon DIDs months if not years ago.

I trust those who worked on DID and the W3C process. There is a deadline for responses to that so that should be a priority, And it is relevant to WebIDs, because there are some aims in common. Btw. you may want to look at solid/did-method-solid#1

@bblfish -- I think WebIDs are almost if not entirely orthogonal to DID Core, which I believe is to exit CR by the end of July, with PR by end of September. @burnburn, @brentzundel, @msporny, or @iherman -- please comment, correct, or confirm.

Per announcement the commenting period ends on the 17th of July. The current plan is to move to PR after that, ie, the WG plans go to PR end of July - early August (and not end of September).

Sorry I sidetracked the discussion to DIDs, above.

It used to be necessary to have the WebID profile be public if one wanted to verify the WebID association to the key as in WebID-TLS. That association was necessary there because we wanted to use the existing Subject Alternative Name field of X509 certificates, and that had to be an identifier for the person, not the key. So that required dereferencing the WebID URL for access control reasons.

If we move to HTTP-Sig we could also give the key an ID and make that alone public, and there are enough use cases for that by itself: eg. to verify that pubic key for a verifiable claim. The KeyId could also link to the WebID. Could the WebID Document then sign something proving control of the key without linking to it? Would that be useful? I don't know.

Anyway: the point is that we can have WebID profile documents that are protected. But that does making linking to them a lot more complicated. That should be obvious, but I think it would help to state that.

The KeyId could also link to the WebID.

This way it doesn't help with anything. I can publish a key linking to your WebID.

Could the WebID Document then sign something proving control of the key without linking to it?

And how do you get public key trusted by that WebID?

In solid/solid-oidc#51 we are currently considering that if WebID Document is not public, it would have to expose authentication relevant relations in Link header of HTTP response of an unauthorized request.

If WebID spec clarifies that the document could be public or protected. Any spec depending on it would need to specify what to do if it's protected.

It might be worth considering that:

• There is no requirements about the RDF representation of a WebID Profile document (apart for it being available as text/turtle at least);
• A FOAF Profile document can be linked to a WebID in its representation (the WebID Profile document) as foaf:isPrimaryTopicOf thereof, which makes such documents (some of which could be public and others private) the right place to store arbitrary information about the referent of an URI.

Therefore, you could very well dereference a WebID profile document, say:

GET /alice#
HOST: example.org

HTTP/2 200
Content-Type: text/turtle

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX solid: <http://www.w3.org/ns/solid/terms#>

<https://example.org/alice#>
    a foaf:Agent ;
    solid:oidcIssuer <http://issuer.example.org> ;
    foaf:isPrimaryTopicOf
        <https://pod.example.org/privateFoafProfileDocument>, 
	<https://pod.example.org/publicFoafProfileDocument> ;
.

And keep different bits of information about <https://example.org/alice#> in either a public or private and discoverable FOAF profile document.

The WebID could also potentially not link to anything private if the mere presence of the URI gave up too much information.

So if there is, as per my understanding at least of their nature not necessarily a privacy issue in divulging things that are used to assert control of a WebID (such as an OIDC issuer or say a public key), which also in my understanding seem to be the main reason for a WebID to exist in the first place, then the fact that a WebID's representation is required to be public should not be problematic.