search

w3c / WebID

https://www.w3.org/groups/cg/webid
MIT License
14 stars 7 forks source link

Getting a sense of direction #37

Closed jacoscaz closed 6 months ago

jacoscaz commented 8 months ago

Hi all. I've taken some time to try to integrate the recent bout of activity into a coherent document, which you can find at https://jacoscaz.com/WebID/primary-spec/webid.html .

EDIT: my working draft now lives within this repository:

The feedback to https://github.com/w3c/WebID/pull/27 clearly shows the group's preference towards a more granular approach to changing the spec and this issue is not an attempt to go against such feedback.

What this is, however, is an attempt at integrating most of the past and recent discussion into a practical compromise to be used a functional reference point for further work (namely, a sequence of small, hyper-focused PRs through which to update the current spec). Ultimately, the goal is to establish a sense of direction to help us in the likely case that discussion gets too sidetracked or degenerates into eternal bikeshedding.

It takes very little time to review this document and establish whether it manages to strike an acceptable compromise WRT our respective points of view, needs and sensibilities. I kindly ask you to do so, and let me know what you think.

In terms of open issues, this draft attempts to reconcile and integrate the discussion in:

woutermont commented 8 months ago

Thanks for taking the time to put this together, @jacoscaz! I must say I find that you summarized the growing consensus on multiple issues quite nicely. The serialization aspects deserve some more discussion though, as we haven't really gone into them deeply enough, I believe.

However, I will refrain from making any concrete remarks here on this preliminary bundling of issues, since these topics each have their own place of discussion. I would urge others to do the same.

melvincarvalho commented 8 months ago

Looks very good!

It's key to have the working definitions down somewhere:

WebID An identifier in the form of an HTTP IRI for naming an Agent which, when dereferenced, must always lead to an Identity Document describing the Agent named by the WebID itself.

Identity Document An RDF document that describes an Agent.

Agent A thing that does stuff.

This looks pretty good to be honest, at least as a starting point.

Nit: IRI WebIDs introduce phishing attacks though. Someone could easily be fooled into thinking one character is another. No strong view on this, right now, just an observation.

Client HTTP libraries conforming to the HTTP standard will automatically strip the fragment before sending requests to the server.

Suggest change "will" to "should". Or add "conforming".

While this is true in theory, it may not be in practice. See:

https://github.com/curl/curl/issues/4412

Other than that is looks very good. There will be some small nits to work out. But in general great work, I'd say it's ready for review. Thank you!

webr3 commented 8 months ago

Brilliant work that must have taken quite some time to compile.

A (small?) thing I'd like to point out is that this creates a 1:1 constraint between 1 agent 1 document.

An Identity Document MUST qualify the described Agent as the document's foaf:primaryTopic. Furthermore, an Identity Document SHOULD also qualify the described Agent as having type foaf:Agent.

If those two were swapped, MUST Agent, MAY or SHOULD IF ONE foaf:primaryTopic then the 1:1 constraint, and arguably a limitation, would be removed, allowing more use cases (such as a doc full of a domain:s bot identities, useful to whitelist or verify agents).

kidehen commented 8 months ago

This is a good start, thanks for the time and effort.

Concerns:

  1. Why has "Profile Document" been replaced with "Identity Document" ?
  2. Why does the opening sentence state the following?

WebID defines a standard means by which user agents and servers interact to establish a user's identity, ensuring a structured, decentralized approach for identity discovery on the web.

The title of a spec and its associated abstract are ultra important. Currently, from my vantage point, the spec continues to conflate important terms.

A WebID can't be a system. It is part of an Identification System facilitated by a Profile Document.

If the system being specified is named "WebID" then how do you reconcile the description of a "WebID" under the terminology section? It doesn't work, IMHO.

Suggestion: Can we at the very least try to reach consensus on the following:

  1. Is WebID an HTTP URI (i.e., identifier type) for unambiguous Agent naming; or that it is part of a larger system for identification (and possibly, authentication)?
  2. What is this spec supposed to be about?
  3. Is it about a system and its loosely-coupled components?
  4. is it about something else, not covered above?

One more thing: The current broken spec contains a "Web Identity and Discovery" sub-heading which has now been removed. What's the reason for its removal? In fact, why can't "WebID Identity and Discovery" be the title of the spec? At least that provides some route to WebID as recursive acronym -- which I don't like, but could live with for sake of consensus.

In the scenario above, the spec would clearly state that WebID is a recursive acronym as part of its abstract nature.

melvincarvalho commented 8 months ago

The title of a spec and its associated abstract are ultra important

I believe what is there now is a working title but @jacoscaz can correct me if I'm wrong

While brainstorming names, I thought WebID-Core may offer an intuitive option

kidehen commented 8 months ago

While brainstorming names, I thought WebID-Core may offer an intuitive option

'Web Identity and Discovery Core' is clearer. WebID as a recursive acronym is crucial; otherwise, we are just looping on the same bag of issues.

webr3 commented 8 months ago

A WebID can't be a system Is WebID an HTTP URI

WebID is a concept A WebID is an HTTP URI..

Dog, A Dog, My Dog.

melvincarvalho commented 8 months ago

WebID is a concept

Yes, indeed. It is an overloaded term, which is always confusing. But once you realize that, all makes sense.

A more long winded way of saying it might be: "The WebID suite of specifications". Im not sure though, it's a bit of a mouthful.

EDIT: raised https://github.com/w3c/WebID/issues/40

jacoscaz commented 8 months ago

Hi all. Thank you for your feedback. This draft provides an integrated view of the general conversation and I'll do my best to keep this updated as the latter evolves. Once we feel reasonably comfortable with how everything fits together, working on the individual PRs required to bring the current spec on par (functionally) with this draft should be a relatively quick and fairly directed process. In-depth discussion on any given topic is better done within a dedicated issue.

IRI WebIDs introduce phishing attacks though. Someone could easily be fooled into thinking one character is another. No strong view on this, right now, just an observation.

@melvincarvalho this is being discussed in https://github.com/w3c/WebID/issues/10 . I think you've already raised this point there but feel free to do so again if you think that's necessary.

Suggest change "will" to "should". Or add "conforming".

@melvincarvalho "Conforming" is already there?

A (small?) thing I'd like to point out is that this creates a 1:1 constraint between 1 agent 1 document.

@webr3 could you open a dedicated issue detailing the problem and your proposed solution or proposed alternatives? Also, could you indicate whether this is a blocker for you or whether you'd be ok with version 1.0 maintaining a 1:1 constraint, though it may not be your favorite option?

Why has "Profile Document" been replaced with "Identity Document" ?

@kidehen following W3C's note on spec extensibility, we've started referring to "subspecs" as Extension Profiles. The use of the word "Profile" has, therefore, become somewhat confusing. I am sorry I cannot remember off the top of my head who suggested using Identity Document and where.

EDIT: found it - https://github.com/w3c/WebID/issues/22#issuecomment-1826231760 .

The title of a spec and its associated abstract are ultra important. Currently, from my vantage point, the spec continues to conflate important terms.

The current spec has "Web Identity and Discovery" which has now been removed. What's the reason for its removal? In fact, why can "WebID Identity and Discovery" be the title of the spec? At least that provides some route to WebID as an acronym -- which I don't like, but could live with for sake of consensus.

@kidehen after reading the discussion in https://github.com/w3c/WebID/issues/17, I've just changed the title of my draft to Web Identity and Discovery [WebID] 1.0. Does that address the above? I can't make heads or tails out of the argument for the recursive acronym but I do understand how using WebID on its own to refer to different things would be confusing, so I agree that a title change is needed. The reason for the removal is nothing more than the fact that I started the document from scratch and did not put any real thinking into the title. I was working on WebID, so I temporarily titled the document WebID. Renaming is a good call.

melvincarvalho commented 8 months ago

@melvincarvalho "Conforming" is already there?

You are absolutely right. As pointed out above not everything conforms, sometimes not even curl. So, that's fine..

webr3 commented 8 months ago

just changed the title of my draft to Web Identity and Discovery [WebID] 1.0

Minor, is the 1.0 required?

If not, perhaps not having a version would be more indicative of stability

kidehen commented 8 months ago

@kidehen following W3C's note on spec extensibility, we've started referring to "subspecs" as Extension Profiles. The use of the word "Profile" has, therefore, become somewhat confusing. I am sorry I cannot remember off the top of my head who suggested using Identity Document and where.

EDIT: found it - #22 (comment) .

I don't see any justification for the change. Why? Because "Profile Document" is a term that's already broadly used in the existing editors draft, amongst other related docs. I don't recall "Profile Document" usage being a problem for which a new issue has been opened.

melvincarvalho commented 8 months ago

See Also:

The word "Profile" has come to mean so many different things, that I don't believe it adds anything to the definition

from https://github.com/w3c/WebID/issues/22#issuecomment-1819619179

3 choices:

webr3 commented 8 months ago

Apologies, but I think technically it would be a Document containing a description of, or containing a profile, as opposed to being a WebID Profile Document.

Only a small part of an unknown sized document is potentially being outlined by any would be specifications here, we can specify the foundation of a WebID Profile, a vocab and some guides to it's partial or full usage, but we're not in defining a media type territory here, so appending the word document perhaps doesn't fit.

Is a, has a, contains a.

jacoscaz commented 8 months ago

I don't recall "Profile Document" usage being a problem for which a new issue has been opened.

@kidehen This is very true. I've changed my draft back to "Profile Document". We can discuss in a dedicated issue if needed.

jacoscaz commented 8 months ago

/chair hat on

Ok, thanks everyone for your feedback. This was very useful. Next, I would invite you to focus on:

kidehen commented 8 months ago

@kidehen after reading the discussion in #17, I've just changed the title of my draft to Web Identity and Discovery [WebID] 1.0. Does that address the above?

Yes.

You could tack on 1.0 for added qualification purposes.

melvincarvalho commented 8 months ago

I would not feel comfortable attempting at making changes to the current spec without a more formal process that goes beyond lazy consensus

Could I encourage people to add hyperlinks to phrases like 'current spec', 'draft spec', 'the spec', 'this spec' going forward.

The WebID 2014 ED has been stable for 10 years, so any changes to that would be a big deal, and involve multiple stake holders. We would need quite a big mandate, and process, to start changing that. Also, it's unclear that you ( @jacoscaz ) really signed up for the task of changing this historical spec. And we dont want to burn you out, after your very generous offer to help.

What I suggest is the following: Let's focus on getting the superset spec into a shape and state that the group is happy with. We have a mandate to do that, we have the resources. Then we will see the delta between how we, as a group, would like to define a WebID. The WebID 2014 ED will THEN be able to apply that delta (or not). That in turn, will inform the serialization choices. You can do it the other way round but it's logically more difficult and risky.

At this point we will be able to define a process for those that wish to change WebID 2014 ED and also new profiles such as WebID-JSON-LD can begin, and are able to progress without fear of breaking backwards compatibility, being rebased off a common understanding of what a WebID is.

How does that sound?

jacoscaz commented 8 months ago

/chair hat on

Could I encourage people to add hyperlinks to phrases like 'current spec', 'draft spec', 'the spec', 'this spec' going forward.

@melvincarvalho ya, very good point. I am guilty of not doing so in the first place.

Also, it's unclear that you ( @jacoscaz ) really signed up for the task of changing this historical spec. And we dont want to burn you out, after your very generous offer to help.

@melvincarvalho my goal is to get to a final version of "the spec", or at least understand whether that is possible. As for how to get there, this is up for discussion (hence why I haven't provided the requested hyperlink) and should ultimately be decided by the group. This, in itself, is part of the discussion on process.

Let's see whether we can get to shared common ground when it comes to formats. Process comes next.

webr3 commented 8 months ago

@jacoscaz you wrote in another thread

I'm simply keeping that document up to date as we progress forward.

I hadn't realized, would it be viable to keep your method of working identical, but shift the document as is to this repo, then continue on as you are, such that changes are reflected and visible/logged here?

jacoscaz commented 8 months ago

@webr3 can do. I haven't done so primarily because I only got admin access to the repo a couple of weeks ago and by then I had already started working on it. Also, this being my first time as chair/editor, I'm not well versed in all things process and I did not want to do so without at least consulting the group first.

webr3 commented 8 months ago

Please do, it's wip, and our direction, as opposed to yours that we're commenting on, certainly nothing precludes you just going right ahead and clicking it in :)

kidehen commented 8 months ago

@webr3 can do. I haven't done so primarily because I only got admin access to the repo a couple of weeks ago and by then I had already started working on it. Also, this being my first time as chair/editor, I'm not well versed in all things process and I did not want to do so without at least consulting the group first.

Please do.

melvincarvalho commented 7 months ago

As we near the WebID CG's 12th anniversary, on Jan 17th, let's honor Henry's legacy by planting a seed of his vision of a modular, loosely-coupled social web. Achieving this for our milestone would be a fitting tribute to him and a testament to our collaborative spirit. Let's make it happen.

image

jacoscaz commented 7 months ago

Hi all. I've updated my draft according to the discussion in https://github.com/w3c/WebID/issues/3, which indicates a chance of converging on a MUST on Turtle and JSON-LD for publishers. As for how to get there, I'll open a new issue on all things process momentarily.

TallTed commented 7 months ago

[@jacoscaz] I've updated my draft

By which I think you now mean https://github.com/w3c/WebID/blob/main/working_documents/webid-core-jacopo.html?

jacoscaz commented 7 months ago

[@jacoscaz] I've updated my draft

By which I think you now mean https://github.com/w3c/WebID/blob/main/working_documents/webid-core-jacopo.html?

@TallTed correct, I've also updated the opening comment of this thread with the new URL.

webr3 commented 7 months ago

Hi @jacoscaz - I have a little confusion as there's this document, and the identity document, both changing, and the latter more recently - should pull requests and suggestions be flagged against this or the other?

jacoscaz commented 7 months ago

/chair hat on

@webr3 thank you for asking, perhaps I should have been more clear. This is only meant as a way for me to track consensus. It is not an official working draft. The only working draft is https://github.com/w3c/WebID/blob/main/spec/identity/index.html (and its .bs source file, now that we're using BikeShed). Indeed, I hadn't planned on putting this one in the repo and only did so when some of you asked me to.

Note that I'm fully aware of your preference towards a "clean slate approach" rather than incremental changes to the current working draft. However, the latter is what the group favors and, therefore, where I decided to start from. I personally share your doubts towards whether we can be effective doing so, though, so I'm keeping the "clean slate approach" in mind as a "plan B".

webr3 commented 7 months ago

Cheers!

Perhaps there's no issue with doing both, then periodically seeing the substantial differences between them.

In terms of effort, it feels easier personally to raise suggestions against this one than the other - I don't want to be a thorn in the side by submitting pull requests that just delete large %s at a time on the other!

melvincarvalho commented 7 months ago

My thoughts on a direction are here:

https://lists.w3.org/Archives/Public/public-webid/2024Feb/0002.html

I believe it has mind share in the group.

Please note point 6:

Addressing this by adopting a serialization-neutral definition of WebID could be the initial step, with serialization specifics to follow. This could be as simple as one sentence following another.

Strongly opposed to the proposed hard fork

TallTed commented 7 months ago

The only working draft is https://github.com/w3c/WebID/blob/main/spec/identity/index.html (and its .bs source file, now that we're using BikeShed).

I want to be sure I understand things.

The above suggests that PRs should be made against
https://github.com/w3c/WebID/blob/main/spec/identity/index.bs
as that is the source that somehow now results in
https://github.com/w3c/WebID/blob/main/spec/identity/index.html
which somehow (CI? (which doesn't seem to exist yet)) (should) gets(s) piped to a github.io location (which doesn't seem to exist yet) where it can be viewed in all its browser-rendered glory.

Is that accurate?

jacoscaz commented 7 months ago

/chair hat on

@TallTed, we're slowly sorting out a couple of teething issues with the CI build that come up as we move forward. That said, the CI build flow is there and mostly working (see, for example, https://github.com/w3c/WebID/commit/fea6d252b34d4b5ac29c59125bfb2e47c2223567).

A few pointers:

As of right now, we need to look into why the CI build isn't working within forks, meaning that the CI build isn't doing its magic in a PR like #60 . For your convenience, though, I've just run BikeShed locally and committed the changes as a temporary stopgap. The spec/identity/index.html file from my PR is also statically served (kind of) at https://htmlpreview.github.io/?https://github.com/jacoscaz/WebID/blob/feat/definitions/spec/identity/index.html .

Some of the above should ideally go in our README.md, pointing at the various working items in the repo and their rendered versions. It's a PR on my todo list but I haven't gotten around to it yet and I'd be happy with anyone willing to take it on.

TallTed commented 7 months ago

Generally speaking, it is best practice to not have CI and other processing relics (like the current https://github.com/w3c/WebID/blob/main/spec/identity/index.html) be managed by GIT, so it's clear to any and all which document should be edited (now, https://github.com/w3c/WebID/blob/main/spec/identity/index.bs). README.md content should indeed be updated, but knowing typical (lack of) reading patterns, it should not be relied upon as the only signal not to edit https://github.com/w3c/WebID/blob/main/spec/identity/index.html, which would be the target of PRs in most other WGs & CGs with which I'm involved.

jacoscaz commented 7 months ago

/chair hat on

Generally speaking, it is best practice to not have CI and other processing relics

Good suggestion @TallTed ! @woutermont , what do you think?

melvincarvalho commented 6 months ago

WebID as a recursive acronym is crucial

...

which I don't like

-1

No. I dont believe WebID has ever been a recursive acronym. I dont think anyone likes this, or that anyone else is suggesting it.

jacoscaz commented 6 months ago

/chair hat on

Closing as outdated. The only major topic covered by my personal working draft that's still left to address is serialization formats but the discussion around it has progressed further (see #61 and #66), deviating from the draft itself. Pending minor topics are also being tracked on their own (#10 and #20).