Basic definitions

[jacoscaz]

Hi all. This is the first RFC thread I open and, as such, also served as a test of the RFC process itself. For more context on RFC threads, please refer to https://lists.w3.org/Archives/Public/public-webid/2023Nov/0121.html .

I kindly ask you all for your feedback on the definitions below. These are mostly @kidehen's work, although I've adapted the first one to keep closer to the current version of the spec. As per the email linked above, this is not meant to be a discussion thread. Please limit yourselves to just one comment per each of you (but feel free to have as many separate discussions about this as you want!).

1. WebID -- an identifier in the form of an HTTP URI for unambiguously naming an Agent which, when dereferenced, must always lead to a WebID-Profile Document describing the Agent named by the WebID itself.

2. WebID-Profile Document -- a document that describes an Agent named using a WebID

3. WebID-TLS -- an authentication protocol for verifying credentials expressed in an WebID-Profile Document

4. WebID-OpenIDConnect+OAuth -- an authentication protocol for verifying credentials expressed in an WebID-Profile Document

[jonassmedegaard]

I do not like that the definition of a WebID depends on the definition on WebID-Profile.

Seems adequate (and therefore preferred) to limit the definition of a WebID to what it is, without including how it may optionally be directly used to get the RDF contents of what is identified (i.e. what is separately defined as a WebID-Profile), nor how it may optionally be validated (i.e. what is defined by other WebID-* definitions). That structure forms a directed graph of definitions, avoiding cycles.

[kidehen]

I do not like that the definition of a WebID depends on the definition on WebID-Profile.

Also, the proposed wording seem ambiguous to me: Is a WebID required to never fail to dereference, in order to comply with the later "must always"? Or conversely is the "must always" effectively a "maybe if possible"?

Seems an awful lot easier to me to define a WebID as only an identifier, without defining at all how that identification is validated. And then separately define in the WebID-Profile definition that it is a mechanism to validate a WebID, by serving it as the endpoint of a WebID, and as content reiterating that same fact using RDF (without defining which serialization of RDF is used - leaving that to WebID-XXX protocol definitions).

The following WebID resolves to a profile document without introducing content-negotiation or any other distraction.

https://kingsley.idehen.net/DAV/home/kidehen/Public/YouID/link-in-bio-credentials-5/index.html#netid

The moment "#" is taken out of the naming mix, you introduce content-negotiation -- if you seek unambiguous entity naming.

[kidehen]

Also, the proposed wording seem ambiguous to me: Is a WebID required to never fail to dereference, in order to comply with the later "must always"? Or conversely is the "must always" effectively a "maybe if possible"?

I was responding to: Also, the proposed wording seem ambiguous to me: Is a WebID required to never fail to dereference, in order to comply with the later "must always"? Or conversely is the "must always" effectively a "maybe if possible"?

My point: A WebID is a name, so there has to be indirection from its sign aspect to its connotation aspect. Basically, it MUST resolve, since it is a name.

Resolution only introduces content-negotiation (and associated headaches) if "#" isn't used as part of the signage aspect of the name -- hence my example re https://kingsley.idehen.net/DAV/home/kidehen/Public/YouID/link-in-bio-credentials-5/index.html#netid

For others, my example breaks down as follows:

1. https://kingsley.idehen.net/DAV/home/kidehen/Public/YouID/link-in-bio-credentials-5/index.html#netid -- denotation (signage)
2. https://kingsley.idehen.net/DAV/home/kidehen/Public/YouID/link-in-bio-credentials-5/index.html -- connotation (description obtainable from that address)

1 + 2, via indirection (implicit due to "#") is what makes a Name. Unambiguous naming via indirection just happens (implicitly), courtesy of "#" .

Thus, if the "#" is removed we need to achieve the same effect (unambiguous entity naming) via an HTTP 303 (as demonstrated by DBpedia's approach) i.e., explicit indirection via HTTP redirection. Even more work, if we seek to use a URN schema for unambiguous entity naming.

[jacoscaz]

@jonassmedegaard @kidehen as per my introduction, I kindly ask you to move any back and forth that goes beyond your respective feedback to other places (here on GitHub or on the list).

@kidehen: @jonassmedegaard has provided feedback in the form of this first comment (https://github.com/w3c/WebID/issues/22#issuecomment-1810572993). If you want to have a discussion about it - which I invite you to do! - I kindly ask you to have such discussion anywhere else but in this issue. Instead, I would appreciate your opinion on the changes I made to the first definition, that of WebID, to which I added which, when dereferenced, must always lead to a WebID-Profile Document describing the Agent named by the WebID itself.

Also looking forward to feedback from @acoburn, @tallted, @woutermont, @namedgraph, @csarven , @timbl just to name a few of those I've interacted with over the last few years.

[jacoscaz]

If, however, we want to keep this thread clean to only carry comments tied directly to the original post, then we can now both delete these additional comments.

I would very much appreciate keeping this thread clean to only carry comments tied directly to the original post. Thank you!

[jacoscaz]

Don't be shy! If you have feedback, don't hesitate.

[TallTed]

[@jacoscaz] Don't be shy! If you have feedback, don't hesitate.

I cannot speak for anyone else, but I find this "RFC thread" concept (which concept I have not encountered anywhere else in 35+ years of interaction on the 'net) difficult to work with, at best, and it does not encourage me to participate.

Among other things, it removes background conversation from the thread once those who are actively participating in that portion of the thread have reached some agreement, meaning that others cannot see and replay that discussion for themselves. (For immediate example, there was evidently some conversation above on this page, but it is no longer available for others to possibly be persuaded by.)

Actual discussions (NNTP or mailing list style; not like what GitHub has built, which are closer to StackOverflow-stye Q&A pages) generally preserve that thread. Allowing for such discussions only "somewhere else" means that readers of this page must seek out those other locations in order to participate. This amounts, to my mind, to an artificial roadblock to such participation.

As best as I can make out, you're actually trying to achieve something like wiki article end-results without the article history provided by a wiki (again, I cannot recommend GitHub's reinvention of the wiki, which doesn't provide email alerts of updates nor easy comparison of arbitrary page versions), and I wonder why such a wiki workspace (or even some git-managed files!) isn't being used.

[jonassmedegaard]

I fully agree with the concerns raised by @TallTed.

[jacoscaz]

Hello @TallTed and @jonassmedegaard ,

thank you for your feedback!

which concept I have not encountered anywhere else in 35+ years of interaction on the 'net

First of all, I should recognize that I've been alive for roughly the same time you've been an active netizen. You, along many others in this group, have seen a lot more that I did.

I've never seen RFC threads in public discourse on the internet, either, but I've used them multiple times in my professional life precisely in contexts where discussion would struggle to evolve into decision, to great success. Given the history of this group, I thought trying something different would be a worthy endeavor.

For immediate example, there was evidently some conversation above on this page, but it is no longer available for others to possibly be persuaded by

This is intended. The point of an RFC thread is not to persuade others or be persuaded by others but to materialize a snapshot of where each of us stands on the subject of the thread. In turn, this makes locating consensus and directing further discussion where consensus is missing a lot easier. Furthermore, it gives participants a chance to make their point organically and completely, not too far from what argumentative essays allow us to do in school.

There's another tool which is much commonly used on the internet for a similar purpose - voting. Here on GitHub, it is often implemented by counting either +1s or reactions in the form of emojis. At this stage I am wary of calling for votes, however, as I feel that voting would disregard the technical merits of 12 years of discussion.

Is there any way I can convince you to indulge me in this attempt at using RFC threads to make some progress towards WebID 1.0? I'm not married to the concept and I'd be happy to abandon it should it prove counter-productive. Given previous experiences, however, I'd still like to try.

[acoburn]

Related to the definitions, I agree with @jonassmedegaard's point about circularity: WebID depends on WebID-Profile Document, which depends on WebID.

Perhaps the definition of WebID could be simply:

1. WebID -- an identifier in the form of an HTTP URI for unambiguously naming an Agent

Second, could we shorten the name of "WebID Profile Document" to just "WebID Document"? The word "Profile" has come to mean so many different things, that I don't believe it adds anything to the definition.

2. WebID Document -- a document that describes an Agent named using a WebID

3. WebID-TLS -- an authentication protocol for verifying credentials expressed in a WebID Document

4. WebID-OpenIDConnect+OAuth -- an authentication protocol for verifying credentials expressed in a WebID Document

Third, the WebID-TLS and WebID-OpenIDConnect+OAuth items suggest that credentials are expressed in a WebID Document. I do not believe that is strictly true. Instead, those protocols use the associated WebID Document to verify credentials. That is, those documents contain data that a third party can use to verify a credential. (I don't know if we need to introduce the concept of a "credential subject" here or just leave the definition open-ended)

Finally, (minor) in the initial proposal for definitions, there is an inconsistency in the use of "a" and "an" when referring to WebID. Those could all be changed to "a".

[jacoscaz]

Excellent feedback @acoburn , thank you for taking the time!

[woutermont]

Apologies for the late reaction; I have been postponing a lot of things due to personal reasons.

[Aside:] Contrary to most, apparently, I think this RFC-style gathering of feedback is a welcome addition to the endless issue threads we often see. Provided, of course, that such discussions still have a clear public platform (e.g. Github Discussions, other issues ...), and have had the time to go back and forth for some time, an RFC can be a good way for editors/chairs to have a moment-in-time assessment of where people stand towards adopting certain decisions/phrasing.

---

To aid in the understanding of my feedback, allow me to give a few higher-order semiotic definitions I tend to work with when conceptualising representation on the Web.

• Identity: a representation of an entity, consisting of a subset of the entity's characteristics that uniquely distinguish it from other entities.

• Identity Document: is a document that represents an Identity.

• Identifier: a minimal Identity (or identity-like representation), i.e. the smallest subset of an entity's characteristics that still allows one to uniquely refer to that entity, serving as a token (a sign, often a symbol) referencing the entity.

• Dereferenceable Identifier: an Identifier that can be dereferenced to an Identity Document describing the Entity it represents.

• RDF-Dereferenceable Identifier: a Dereferenceable Identifier that dereferences to an RDF Source.

---

Concretely then, the feedback:

1. WebID -- an identifier in the form of an HTTP URI for unambiguously naming an Agent which, when dereferenced, must always lead to a WebID-Profile Document describing the Agent named by the WebID itself.

This is a good definition i.m.o. It characterises the WebID as a Dereferenceable Identifier naming an Agent and using the HTTP protocol.

Contrary to @jonassmedegaard and @acoburn, I think the definition of a WebID necessarily depends on that of the document it references. The document and it's structure is the dependency, the WebID the depender, even if their names might mislead us to think otherwise. Importantly, one could use the same Identity Document using multiple Identifier types (e.g. a DID that dereferences to the same document as a WebID).

2. WebID-Profile Document -- a document that describes an Agent named using a WebID

Agreed with @acoburn that 'Profile' could perhaps be dropped for clarity. On the other hand, I believe it is conceptually more correct to drop 'WebID' from it, since the document itself does not depend on the Identifier (but the other way around; see above). An alternative terminology avoiding both could be 'Identity Document' (which I'll use from here on).

This definition contains the core (a WebID Profile Document as an Identity Document of an Agent), but

• the mention 'using a WebID' is not necessary (and creates the circular dependency @jonassmedegaard wants to avoid); and
• this definition needs to be extended to include the expected structure of the document: an RDF document with as foaf:primaryTopic the Agent, which contains information that can authenticate the Agent (e.g. Cert. Key or OIDC Issuer). Without this, the WebID spec amounts to little, since the power of it lies precisely in what we can expect to find when dereferencing a WebID. This can depend on the mechanism, but needs to be mentioned in abstracto in the Identity Document definition (e.g. as a specification-profile-based extension point of which WebID-TLS and WebID-OIDC are extension profiles).

3. WebID-TLS -- an authentication protocol for verifying credentials expressed in an WebID-Profile Document

This seems wrong. As @acoburn pointed out, the use case is not "verifying something that contained in the Identity Document", but rather "verifying the Agent's Identity (i.e. authenticate the Agent) using something from the Identity Document".

As stated in re 2., I would explicitly define WebID-TLS as an extension profile of WebID.

[Suggestion] WebID-TLS: an extension profile of WebID, defining an proof-of-posession authentication protocol that authenticates Agents by matching a given private key to the public key declared in their Identity Document.

4. WebID-OpenIDConnect+OAuth -- an authentication protocol for verifying credentials expressed in an WebID-Profile Document

Likewise, as in 3, both re definition as re extension profile.

Minor: I would shorten to WebID-OIDC, and I don't get why OAuth should be in the name here.

[Suggestion] WebID-OIDC: an extension profile of WebID, defining an OIDC-based authentication protocol that authenticates Agents using the OpenID Provider declared in their Identity Document.

Hope to have been of help 🙂

[jacoscaz]

@woutermont another example of excellent feedback. Thank you!

Provided, of course, that such discussions still have a clear public platform (e.g. Github Discussions, other issues ...), and have had the time to go back and forth for some time, an RFC can be a good way for editors/chairs to have a moment-in-time assessment of where people stand towards adopting certain decisions/phrasing

This is exactly my intention. So far, the two RFC thread focus on matters that have been touched upon many times. Please do let me know the moment I call for an RFC on something that would have deserved more discussion in preparation for that.

[TallTed]

I think it's important to start linking these RFC threads to (some of, at least one of) their precursor discussion threads, to both (a) insure that such discussion threads do exist and (b) provide people who may be new to the topic of the RFC thread with a way to catch up on "the discussion to date".

[kidehen]

There still appears to be confusion about what a WebID is, so here's another collection of anecdotes that hopefully brings clarity to the issue at hand:

A passport number and a passport document used by a traveler.

A passport number is an identifier that unambiguously denotes a person -- this is what a WebID is all about. A passport is a document comprising credentials pegged to a subject denoted by a passport number -- this is what a WebID Profile document is all about.

Passport authentication is an act of verifying credentials associated with a passport number.

You can also think about a driver's license number and a driver's license document.

A WebID, Profile Document, and Authentication Protocols are 3 distinct things that are loosely related.

[melvincarvalho]

Hi all. This is the first RFC thread I open and, as such, also served as a test of the RFC process itself. For more context on RFC threads, please refer to https://lists.w3.org/Archives/Public/public-webid/2023Nov/0121.html .

I kindly ask you all for your feedback on the definitions below. These are mostly @kidehen's work, although I've adapted the first one to keep closer to the current version of the spec. As per the email linked above, this is not meant to be a discussion thread. Please limit yourselves to just one comment per each of you (but feel free to have as many separate discussions about this as you want!).

1. WebID -- an identifier in the form of an HTTP URI for unambiguously naming an Agent which, when dereferenced, must always lead to a WebID-Profile Document describing the Agent named by the WebID itself.

I've always said

A WebID is an HTTP URI that denotes an Agent

(any similar wording is fine)

2. WebID-Profile Document -- a document that describes an Agent named using a WebID

I dont think this is right. Any number of documents could describe a WebID

The profile document is obtained from the WebID (e.g. after removing the #)

3. WebID-TLS -- an authentication protocol for verifying credentials expressed in an WebID-Profile Document

Could the key be in another document?

4. WebID-OpenIDConnect+OAuth -- an authentication protocol for verifying credentials expressed in an WebID-Profile Document

Slight nit: having "-" and "+" in the same thing doesnt scan well.

All looks fine, in general

[melvincarvalho]

There still appears to be confusion about what a WebID is, so here's another collection of anecdotes that hopefully brings clarity to the issue at hand:

A passport number and a passport document used by a traveler.

A passport number is an identifier that unambiguously denotes a person -- this is what a WebID is all about. A passport is a document comprising credentials pegged to a subject denoted by a passport number -- this is what a WebID Profile document is all about.

Passport authentication is an act of verifying credentials associated with a passport number.

You can also think about a driver's license number and a driver's license document.

A WebID, Profile Document, and Authentication Protocols are 3 distinct things that are loosely related.

Very quickly on this. I dont think it's right. A passport number can be written on a piece of paper, which doesnt mean that paper is a passport. A WebID can be used to obtain a document, but a passport number cant. The WebID and the WebID document are not loosely coupled.

[jonassmedegaard]

Quoting Melvin Carvalho (2023-11-30 13:08:48)

There still appears to be confusion about what a WebID is, so here's another collection of anecdotes that hopefully brings clarity to the issue at hand:

A passport number and a passport document used by a traveler.

A passport number is an identifier that unambiguously denotes a person -- this is what a WebID is all about. A passport is a document comprising credentials pegged to a subject denoted by a passport number -- this is what a WebID Profile document is all about.

Passport authentication is an act of verifying credentials associated with a passport number.

You can also think about a driver's license number and a driver's license document.

A WebID, Profile Document, and Authentication Protocols are 3 distinct things that are loosely related.

Very quickly on this. I dont think it's right. A passport number can be written on a piece of paper, which doesnt mean that paper is a passport. A WebID can be used to obtain a document, but a passport number cant. The WebID and the WebID document are not loosely coupled.

You can also write a WebID in a piece of paper, or on a web page, or in an RDF graph, without that paper/page/graph becoming a WebID Document.

A Passport number can be used to obtain further data for authenticating the agent represented by that passport.

I like the analogy, which to me also highlights how it would be wrong to strongly couple identifier (WebID or Passport number) with identification data (WebID Document or photo+name+eye color+blood type), because different users might want to explore varying approaches to that (e.g. EU might standardize on storing in iris scan profile, while the US or China might consider that unethical).

Similarly, strongly coupling identifier with specific lingo (e.g. mandating JSON-LD) might seem an optimization to some, but I am not sure China would agree that citizen identifiers must use english descriptors and latin letters, regardless of eficiency globally.

• Jonas

--

• Jonas Smedegaard - idealist & Internet-arkitekt
• Tlf.: +45 40843136 Website: http://dr.jones.dk/

• Sponsorship: https://ko-fi.com/drjones

  [x] quote me freely [ ] ask before reusing [ ] keep private

[kidehen]

Very quickly on this. I dont think it's right. A passport number can be written on a piece of paper, which doesnt mean that paper is a passport. A WebID can be used to obtain a document, but a passport number cant. The WebID and the WebID document are not loosely coupled.

The point I am making, explained differently is as follows: The passport number or passport document are routes to the credentials that make up the passport. Whenever you pass through immigration your passport number is scanned in order to access credentials associated with your passport.

In Web parlance, this means: A URI (e.g., WebID) or URL (denoting WebID-Profile Doc Content Location) are routes to the same credentials usable by authentication protocols.

[kidehen]

2. WebID-Profile Document -- a document that describes an Agent named using a WebID

I dont think this is right. Any number of documents could describe a WebID

Alternatively:

WebID-Profile Document -- a document about an Agent named using a WebID.

[woutermont]

I must express how flabbergasted I am be the sheer incapability of people to follow a simple request of the issue starter (and chair of this CG). @jacoscaz has repeatedly asked to treat this issue as an RFC thread, to limit ourselves to one comment each, and to have discussions elsewhere. Yet the majority of responders somehow feel that this is not addressed to them.

Can we please removehide the responses (including this one) and continue in line with what was asked?

Edit: clarified my language.

[melvincarvalho]

Deleting items can be concerning for some, as it potentially limits the historical record. This is why a number of people favor working with mailing lists, where deletion is not an option, over platforms like GitHub.

[jacoscaz]

@woutermont I very much appreciate your comment and support. Thank you!

I should also add, though, that RFCs are just a tool that I am experimenting with as previous experiences have brought me to believe it may help with some of the group's struggles in finalizing the spec. I am absolutely open to feedback and I would have no issue dropping RFC threads entirely should the majority of active participants find them unpalatable. So far there seems to be a 50%/50% split.

For transparency: I do not have the power to delete responses (yet?) and even if I did, I would hesitate to use it. I've renamed this issue to "Basic Definitions", dropping the "[RFC]" prefix, to reflect its internal state. Nonetheless, I still kindly ask participants to please approach this conversation in the spirit of an RFC thread, at least insofar as willing or capable. I'll open a separate RFC later.

[woutermont]

To clarify: by 'remove' I mean to hide them, which @jacoscaz should be able to do (as well as each person on their own comments). I fully agree that permanent deletion is not the way to go.

[jacoscaz]

Hi all,

Based on all the feedback above, I've pieced together the following definitions:

• WebID: an HTTP URI that denotes an Agent and dereferences to an Identity Document describing such agent.

• Identity Document: an RDF document that describes an Agent, consisting of at least one statement identifying the agent as the document's foaf:primaryTopic.

Of course, as with most compromises, these are unlikely to make everyone as happy as everyone could be. The goal, however, is to have something that makes nobody, or as few of us as possible, unhappy to the point of considering it a no-go.

What do you think? @woutermont @jonassmedegaard @melvincarvalho @kidehen @acoburn @TallTed

Please be explicit in terms of what you consider a no-go vs. what you'd rather do differently but are ultimately ok with.

EDIT: fixed non-uniform capitalization of Agent

[melvincarvalho]

WebID: an HTTP URI that denotes an agent and dereferences to an Identity Document describing such agent.

+1 seems reasonable at first glance

Identity Document: an RDF document that describes an Agent, consisting of at least one statement identifying the agent as the document's foaf:primaryTopic.

-0 I understand it's a compromise solution, and that it's imposslbe to please everyone, though it's tied to FOAF which I think is no longer maintained.

I would not implement this personally, though it's a reasonable way to go.

I would rather use one of inverse terms either foaf:isPrimaryTopicOf or schema:mainEntityOfPage. I would NOT use foaf:primaryTopic myself, I dont think. But may interop with WebIDs that do.

[melvincarvalho]

A more general formulation of (2)

Identity Document: an HTTP document that describes an Agent, consisting of at least one statement tying the agent to the Identity Document

Then: explain the terms Agent and Primary Topic

Note that in FOAF a group can be an Agent too, and groups can have sub members. Would those sub members be WebID's too? That is for the CG to decide.

[jacoscaz]

which I think is no longer maintained.

@danbri @libbymiller what is the state of FOAF? The http://www.foaf-project.org website doesn't seem to work anymore and http://xmlns.com/foaf/0.1/ has a few warnings mentioning the fact that it's temporarily serving an older version as they work on restoring from backups. https://www.iptc.org/thirdparty/foaf/ has what I think is the most up-to-date version of the spec.

[libbymiller]

hi, I'm investigating!

[jacoscaz]

thank you @libbymiller for your time, much appreciated!

[TallTed]

Also note https://web.archive.org/web/20211024073639/http://xmlns.com/foaf/spec/

[danbri]

Update! Thanks Libby :) We can confirm (a) no data loss including no version history loss (b) it's all stashed in multiple places including a (currently private) Github repo. There's an Apache2 server on a Google Cloud VM doing very little except serving the FOAF website filetree as checked out from Github. Additional cleanup is needed for https://, to disentangle less critical sites from the stuff we shouldn't break or lose, and to figure out exactly what to do about userid mappings if git / github become the new source of truth.

https://github.com/foaf/foaf/issues/1#issuecomment-1868108274

[jacoscaz]

Thank you @danbri for following up - much appreciated!

[woutermont]

@jacoscaz, to get back to the draft definitions you provided: they are both workable drafts i.m.o.

Two minor points (preferable for me):

• I would use "about" rather than "describes". Since the WebID spec is a tool to enable a lot of other mechanisms (of which description can be one), I'd rather leave it open if the Identity Document actually provides any kind of "description" except in its broaderst but trivial sense (it contains at least a triple with the Agent as a node).

• The foaf:primaryTopic link is a necessary but foremost practical part of the Identity Document. It does not really have to be in the main definition.

One major point (breaking for me): the core of the Identity Document is to provide a hook for authentication mechanisms. This should really be part of the definition.

Applied to your draft, this gives the following proposal.

• WebID: an HTTP URI that denotes an Agent and dereferences to an Identity Document describing such about that Agent.
• Identity Document: an RDF document that describes about an Agent, providing third parties with one or more ways to authenticate that Agent. An Identity Document MUST consisting of at least one statement identifying the Agent as the Document's foaf:primaryTopic, and one or more statements indicating an authentication mechanism as described by a WebID extension profile.

[jacoscaz]

Thank you @woutermont for your feedback!

I personally like where you are going. However, given the note on the extensibility of specs, doesn't the above imply that a WebID implementation MUST actually implement at least one Extension Profile? If so, this feels like something that would better be stated explicitly.

On the flip side, not everyone in the group might agree on binding the primary spec to the implementation of one of its Extension Profiles. @melvincarvalho @kidehen @jonassmedegaard @acoburn ?

[woutermont]

Given the note on the extensibility of specs, doesn't the above imply that a WebID implementation MUST actually implement at least one Extension Profile? If so, this feels like something that would better be stated explicitly.

Yes, of course. A WebID is useless as long as the agent can't prove that it is actually theirs. Otherwise I could just use your WebID to impersonate you.

The last sentence of my proposal already contains the explicit mention of that requirement. ('MUST consist of ... and one or more statements indicating an authentication mechanism as described by a WebID extension profile')

[jonassmedegaard]

A WebID is useless as long as the agent can't prove that it is actually theirs. Otherwise I could just use your WebID to impersonate you.

Does the URI spec require http - even if it is arguably useless without it? Does http spec require html?

Seems to me that there is no need for the WebID spec to require any specific use. Yes, if no other protocol is consumed then it is unused, but literally not "useless", as that is about its ability to become involved in some other specified (or non-specified) use-case.

[jacoscaz]

@woutermont apologies, I am reading through a lot of activity and got two different comments mixed up in my head. Sorry! Please disregard my comment.

Nonetheless, the question remains of whether the group agrees on binding implementations of the spec to supporting at least one extension profiles.

@jonassmedegaard consider opening a dedicated thread for that specific question. For me, a WebID MUST dereference to an identity document via HTTP(S). So yes, WebID requires HTTP. I am very afraid of what might happen if that also becomes a point of contention.

[woutermont]

Nonetheless, the question remains of whether the group agrees on binding implementations of the spec to supporting at least one extension profiles.

I think that's precisely what @jonassmedegaard is challenging (the HTTP question was just an analogy).

But I believe the analogy is wrong.

• URI does not require HTTP because its purpose is not to transfer hypertext messages. HTTP does not require HTML because its purpose is not to provide a way to write linked markup documents. The correct analogy here would be that HTTP does also not require WebID, because its purpose is not to authenticate agents.

• On the other hand, HTTP does require URI, since to perform its purpose of transferring hypertext it needs a way to address hypertext resources. HTML kind of requires HTTP (or at least one transfer protocol supported by the browser), because to fulfill its purpose of writing linked markup documents, it needs at least one way for browsers to follow those links. Similarly, WebID needs at least one authentication mechanism in order to fulfil its purpose.

[jacoscaz]

/chair hat off

Yes, of course. A WebID is useless as long as the agent can't prove that it is actually theirs. Otherwise I could just use your WebID to impersonate you.

Similarly, WebID needs at least one authentication mechanism in order to fulfill its purpose.

IMHO, a version of one of these should end up in the introductory sections of the spec, to further clarify the relationship between the primary spec and its extension profiles.

[melvincarvalho]

Thank you @woutermont for your feedback!

I personally like where you are going. However, given the note on the extensibility of specs, doesn't the above imply that a WebID implementation MUST actually implement at least one Extension Profile? If so, this feels like something that would better be stated explicitly.

On the flip side, not everyone in the group might agree on binding the primary spec to the implementation of one of its Extension Profiles. @melvincarvalho @kidehen @jonassmedegaard @acoburn ?

FWIW I'm good with any of the definitions at this point. I agree with your sentiment of "not letting the perfect be the enemy of the good". And also there has been enough progress to unblock all my work.

I find it a useful thought experiment to consider an RDF document where a user makes a comment. That user will have a webid, and the webid will be in that document. However the document is not the profile of the webid. If the definitions all work in that scenario, they are probably ticking a lot of boxes.

[csarven]

Responding only to the definitions themselves:

The current WebID 1.0 ED already defines WebID and WebID Profile Document under the Terminology section. They can be clarified with the understanding that the intention is preserved. As for the term "unambiguously", I think that works both in layperson terms and specifically, but I also think that it need not be said because it is a given as per Web Architecture. The URI owner associates a URI to a resource, and there is a social expectation (SHOULD) that they preserve what it identifies.

Regarding the definitions of WebID-TLS, WebID-OpenIDConnect+OAuth:

They don't belong in the WebID 1.0, unless it is relevant for Conformance or Considerations. WebID-OpenIDConnect+OAuth in particular is only speculated - there is no specification or requirement, or even a work item for it.

---

WebID is useful and fulfils the purpose of identifying an agent ("Activity X has actor Y") independently from being employed for authentication.

---

I believe the current intention of WebID + WebID Profile Document is analogous (if not identical) to "RDF-Dereferenceable Identifier". It is technically possible to have a non-RDF-document that describes a given WebID and still be consistent with the Web Architecture. But that's out of scope for what's intended to be detailed in the WebID specification as I see it.

[woutermont]

[@csarven:] WebID is useful and fulfils the purpose of identifying an agent ("Activity X has actor Y") independently from being employed for authentication.

Could you elaborate?

If there is no authentication mechanism, a WebID and its WebID Document are nothing more than just another URI and the RDF Document it derefences to. We don't need a new spec to use those; we already have RDF: If all one needed was a URI pointing to some RDF Document, one could simply ask the user for such a URI.

What we need, and what WebID (should) provide(s), is a way to ensure that URI and the information in that RDF Document are indeed under the control of the Agent we are interacting with.

[kidehen]

• The foaf:primaryTopic link is a necessary but foremost practical part of the Identity Document. It does not really have to be in the main definition.

Yes!

[kidehen]

Applied to your draft, this gives the following proposal.

• WebID: an HTTP URI that denotes an Agent and dereferences to an Identity Document ~describing such~ about that Agent.

How about "resolves to" rather than "dereference" for broader readability?

• Identity Document: an RDF document ~that describes~ about an Agent, providing third parties with one or more ways to authenticate that Agent. An Identity Document MUST consist~ing~ of at least one statement identifying the Agent as the Document's foaf:primaryTopic, and one or more statements indicating an authentication mechanism as described by a WebID extension profile.

That works too, since a profile document is about an agent named by a WebID.

Personally, for sake of clarity, I am more comfortable with:

An Identity Document (a/k/a a Profile Document) MUST comprise at least one statement identifying the Agent as the Document's foaf:primaryTopic, and one or more statements for asserting its type.

A WebID-Protocol Spec (rather than profile) is a separate matter.

[kidehen]

What we need, and what WebID (should) provide(s), is a way to ensure that URI and the information in that RDF Document are indeed under the control of the Agent we are interacting with.

The problem with this riddle is that its solution depends on where you start. If you start from the point of trying to verify what a WebID is, via machine-computable content in a document, a broadly accepted answer isn't unattainable.

if you start from the notion of a WebID-Profile document, where the prime purpose is identification, a broadly accepted answer is attainable -- since this document will comprise an entity relationship graph where entity relationship type semantics are machine-computable (or readable).

My rolling analogy: Trying describing the purpose of a Passport Number vs the Passport itself. What's makes the Passport Number an Identifier that denotes a Person unambiguously?

[woutermont]

[@kidehen:] How about "resolves to" rather than "dereference" for broader readability

I know they are often used interchangeably in common language, but in specifications "resolving" often specifically means disambiguating the identifier (e.g. a relative URI reference is resolved to an absolute one), while "dereferencing" always clearly incorporates the extra step of actually trying to retrieve the meaning of that disambiguated (resolved) identifier (e.g. fetching a representation of the resource identified by the URI). That's why I prefer "dereference", but I won't press much if the group decides otherwise.

[woutermont]

Re purposes, I'm going to appropriate your analogy, @kidehen. I think there is some value in the distinction you make, but just as how a Passport Number only has purpose relative to the Passport, a WebID only has purpose relative to the WebID Document. The purpose of both identifiers comprises mostly of refering to their respective document (in a dereferenceable way, to be practically useable). They stand, as it were, in service of another (higher) purpose. Thus, when I say "the purpose of a WebID," I actually mean "the purpose of a WebID Document, and therefore the indirect purpose of a WebID" (but that is quite long to write/read).

[csarven]

WebID is useful and fulfils the purpose of identifying an agent ("Activity X has actor Y") independently from being employed for authentication.

Could you elaborate?

Wouter, I mean as far as what the definition of WebID (the identifier) includes/entails, i.e., an HTTP URI based identifier to denote agents. Referencing a WebID (in an RDF statement for example) would be a separate use case to an authentication mechanism using WebID.

<https://linkedresearch.org/annotation/csarven.ca/%23i/87bc9a28-9f94-4b1b-a4b9-503899795f6e>
  as:actor <https://csarven.ca/#i> .

<https://csarven.ca/#i>
  foaf:knows <https://wouter.termont.online/> .

[woutermont]

@csarven, I get what you are saying, but my reply remains the same: you don't need WebIDs for that. All the semantics you need is in the RDF there: some node has an actor identified by https://csarven.ca/#i, which knows an node identified by https://wouter.termont.online/, and the two last nodes are Agents (by courtesy of foaf:knows semantics).

As far as I am concerned, we are not writing a spec that, at its core, does nothing more than what we already can do without it 🤔 What a WebID can and should provide extra, is that on interpretation of those statements, you know you can, if so desired, verify that the agent identified by https://csarven.ca/#i is really you, the person Sarven Capadisli, and the one identified by https://wouter.termont.online/ is really me, the person Wouter Termont.

Edit: I am curious, though, as to what other people think of this. I also realise that I do not want to make this a breaking point, because even if not mandatory, every WebID Document that is actively used will end up containing an authentication mechanism anyhow.