Generalize Solid-OIDC protocol beyond WebID

[acoburn]

WebID provides a structured way to identify and refer to agents, but there are now other structured forms of identification, such as Decentralized Identifiers (DIDs) and Verifiable Credentials. The name and protocol of WebID-OIDC is very WebID-centric, and perhaps the protocol should be made flexible enough to accommodate other identity structures, such as those mentioned here but also those that haven't been invented yet.

[RubenVerborgh]

WebID-centric

This hinges on the precise definition of WebID.

The way I would define WebID is as a dereferenceable IRI; that definition also covers DID. I.e., I see no inherent necessity to restrict WebID to HTTP(S).

That said, the compatibility problem for implementations (as discussed with @dmitrizagidulin elsewhere) is what DID resolvers MUST be supported by clients. Because if there's no MUST, there is no guaranteed interoperability.

So while we can write down WebID-OIDC for IRIs in general (and I strongly suggest we do), some other document will need to mandate with schemes MUST be supported by a given system. Then we can make statements such as "x supports WebID-OIDC over HTTP(S)" or "y supports WebID-OIDC over these specific DID resolvers".

[TallTed]

@RubenVerborgh - The current state of WebID draft specifications is that it is restricted to HTTP(S) IRIs. I argued long and hard that this was unnecessarily restrictive; that IRI dereferenceability was the key, and not the specific scheme of the IRI. One eventual outcome was that OpenLink uses NetID to talk about generic dereferenceable IRI-based ID, and WebID only for HTTP(S)-scheme IRIs.

Which is to say, given that WebID-OIDC is built on and inherits WebID, WebID-OIDC is restricted to HTTP(S). NetID-OIDC might be a scheme-agnostic option. Or a group effort might be mounted to update the WebID specs to allow other URI schemes in whatever the next version might be called (since the previous work was never finalized, it's probably not properly called 1.0, even though it's increasingly used in the wild).

[RubenVerborgh]

The current state of WebID draft specifications

They're drafts indeed.

NetID-OIDC might be a scheme-agnostic option.

Let's just release a spec where WebID is not HTTP-specific. There are more mistakes in the draft.

[dmitrizagidulin]

Let's just release a spec where WebID is not HTTP-specific. There are more mistakes in the draft.

+1 to that. (Also, the Web is larger than just http, anyway.)

[TallTed]

Let's just release a spec where WebID is not HTTP-specific

I'm not sure I understand this.

If you mean, release such a Solid spec, I think that's poor practice. "We don't like this part of that draft spec (which may yet exit 'draft' status) so we're changing it in our own."

If you mean, release such a revised WebID spec, I'm with you.

the Web is larger than just http

I agree. There are other people you may need to convince of this.

[jaxoncreed]

Let's just release a spec where WebID is not HTTP-specific. There are more mistakes in the draft.

If we do this, we MUST list the protocols that Solid servers must implement. If a user starts using a DiD on their own custom implementation which is technically spec-compliant, but other spec-compliant servers do not know how to dereference DiDs we've just eliminated interoperability.

[pmcb55]

+1 to releasing a revised WedID spec.

To Jackson's point, I guess making HTTP a MUST supported protocol for Solid makes sense. Anything else (e.g. DID) can be a MAY.

[jaxoncreed]

Anything else (e.g. DID) can be a MAY.

There's still a problem with saying that something like DiD is a MAY. We don't want some servers to be compatible with some identities. A resource server that does not implement DiD will be unable to dereference the identity and therefore unable to qualify its authenticity.

I think we either need to decide if servers MUST implement DiD or not implement it at all.

[bblfish]

The current state of WebID draft specifications is that it is restricted to HTTP(S) IRIs. I argued long and hard that this was unnecessarily restrictive; that IRI dereferenceability was the key, and not the specific scheme of the IRI. One eventual outcome was that OpenLink uses NetID to talk about generic dereferenceable IRI-based ID, and WebID only for HTTP(S)-scheme IRIs.

At one time we did have a notion of a general IRI scheme for WebIDs. The problem was there was no way we could get enough agreement as to all the different ways of verifying those. The group was already way over time to release a spec. So @timbl argued, I think quite correctly that we reduce the scope to https. That helped us get a few specs out of the door, and make it possible to implement them.

Too much generality can be problematic when implementing instances. As long as restrictions don't stop generality coming in later that is not a problem. Remember the web started with URLs. IT was only later that IRIs were standardised.

[bblfish]

That said, the compatibility problem for implementations (as discussed with @dmitrizagidulin elsewhere) is what DID resolvers MUST be supported by clients. Because if there's no MUST, there is no guaranteed interoperability.

Would the proposal for an App Launcher/Keychain help with this? The idea of an App Launcher is that it would play the role of the secure app which all other apps could use to authenticate. That would mean the authenticaiton logic could be centralised in one place.

[TallTed]

@bblfish -

To my mind, the specs we were working on (WebID 1.0 and WebID-TLS) in the WebID Incubator Group (XG) and its successor WebID Community Group (CG) never actually "got out the door" because they were never fed to a WG, and so never graduated to CR nor PR nor even WG-NOTE (never mind TR, though they both have non-existent TR targets as their "latest version" URLs); to this day, they remain as CG Editor's Drafts.

These protocol-focused specs could have been primarily focused on (and required support of only) HTTP(S) for WebID 1.0, without limiting the definition of WebID to HTTP(S)-based URIs. A successor WebID 2.0 could easily add other URI schemes, transfer protocols, etc., without breaking that HTTP(S) support.

This still could be done, if there's enough support for an actual WebID WG and/or renewed energy for polishing the existing drafts for submission to another WG with suitable scope to adopt and advance them.

[kjetilk]

There's also the safe: WebIDs... My short foray into IoT has generally made me uneasy about being too tightly bound to HTTP, I think there are many good cases that can be made for orthogonality, although I have recognized the need to do HTTP first.

It seems hard to maintain orthogonality in this area, but it would be great if we found a way.

[bblfish]

To my mind, the specs we were working on (WebID 1.0 and WebID-TLS) in the WebID Incubator Group (XG) and its successor WebID Community Group (CG) never actually "got out the door" because they were never fed to a WG, and so never graduated to CR nor PR nor even WG-NOTE (never mind TR, though they both have non-existent TR targets as their "latest version" URLs); to this day, they remain as CG Editor's Drafts.

At the time there were people who did everything to block WebID. Ask Manu Sporny: I believe he experienced pushback with much larger community support.

You need a lot of players to push for something to become a WG. For that the best thing is to build things that work and grow adoption. That is what counts. The Web grew before the W3C existed. If Solid grows then standards will come from themselves.

[TallTed]

@kjetilk

There's also the safe: WebIDs

Well... Those are safe: scheme URIs, which are apparently being used and accepted as WebIDs by some systems, but they are not WebIDs according to the definitions in the existing draft specs, which restrict WebIDs to http/s: scheme URIs.

Again -- I am in favor of WebID being more broadly defined. But if Solid is pointing to the draft WebID specs as authoritative, then either those drafts must be updated, or Solid must cease to use non-HTTP-based URIs as WebIDs. Updating those drafts has a relatively low bar -- as they are (officially if not technically) under the control of the (moribund but extant) WebID CG -- and some updates should be pursued there regardless of the URI scheme issue, such as fixing the bad latest version links.

[elf-pavlik]

Latest draft has hard dependency on WebID https://github.com/solid/authentication-panel/blob/master/oidc-authentication.md

Would someone like to take leadership with respect to resolving this issue?

[justinwb]

Latest draft has hard dependency on WebID https://github.com/solid/authentication-panel/blob/master/oidc-authentication.md

Would someone like to take leadership with respect to resolving this issue?

It seems that earlier rough consensus on this thread was to provide an updated WebID draft to expand beyond HTTP. What wasn't clear to me from that consensus was whether that would specifically include DID in that expansion, or by expanding we only aim to not exclude it from being supported later by saying the WebIDs aren't limited to HTTP only.

[acoburn]

This issue has been open for nearly two years. It seems that the general consensus is that we would like to represent agent identity as some form of an identifier that can be dereferenced as an RDF document. That general opinion seems to include, but not be limited to, such underlying protocols as DID and WebID.

As the specification currently stands, there is a tight connection to WebID. Unfortunately, the WebID draft specification is still a draft with no clear movement toward recommendation status.

I would like to make a specific proposal that the Solid-OIDC specification not normatively require WebID as it does today. It would not exclude the use of WebID, but by being more generic, it avoids some of the problematic portions of the current WebID draft. In particular:

• the current use of "Client WebID" in Solid-OIDC conflicts with the WebID draft's requirement to serialize resources as Turtle
• the current requirement of WebID URLs to use the HTTP(S) scheme excludes DIDs

I opened https://github.com/w3c/WebID/issues/3 in an attempt to move the WebID document in a more flexible direction, but the initial comments do not appear to be going in that direction.

[bblfish]

Yes, it would be good to have others in the community give feedback on how they think we could proceed with the issue brought up by @acoburn .

Note that the more you generalise, the more complicated things become in terms of engineering and debugging. Oddly that does not seem to be the case in Mathematics where short proofs starting from very abstract principles are valued, because they are for those in the know, easier to oversee. See the recent talk by Kevin Buzzard on formalizing mathematics in Lean. Even there though, it helps often to rewrite proofs from simpler premises to help explain the concepts to undergraduate mathematics students.

In the web space, on the issues we are discussing, leaving formats and protocols open, creates requirement on clients to implement parsers for those formats and protocols. This is because we are aiming at interoperability. So say you want DID's: then you potentially require every implementor to implement all DID protocols. So it looks all nice and open to everyone, but you can massively increase the complexity of adoption of Solid in the process of doing so. There are then questions as to how much resources the community has at this point. As time goes by, more resources may be available, and things that are complicated now, may be affordable then.

Indeed, your argument @acoburn, is built on the use case that people have trouble deploying WebID because they are using github to publish their code which makes content-negotiation difficult or impossible. In order to overcome that problem, you are arguing that developers should prepare to deal with all the generality that DIDs and all the RDF mime types.

There must be more pragmatic ways to deal with this issue. I did propose one. But I have often found that sleeping over an issue and listening to others brings up new better options.

[acoburn]

your argument @acoburn, is built on the use case that people have trouble deploying WebID because they are using github to publish their code which makes content-negotiation difficult or impossible

That is one problem. There are others.

Another problem is that the WebID draft is just a draft. Depending on a draft is problematic because that dependency can change at any time.

What I am suggesting is that we think about WebID in the same way Solid thinks about LDP: it is possible to use it but it is not a hard dependency. By removing the normative dependency on the WebID draft, it means that we are able to build Solid-OIDC on a much more stable foundation, especially one that allows for future growth in the direction of DIDs (that direction is not possible with the strict dependency on WebID).

In fact, the Solid-OIDC document is attempting to be very specific about the sort of thing that matters to OIDC: serialization format, but that conflicts with the WebID specification. As things currently stand with Solid-OIDC w.r.t WebID we are left with having to hand-wave about serialization requirements, effectively saying: "just ignore that part of the WebID spec". That's not a good position to be in. The only real solutions there are to: (a) change the WebID spec (b) change the Solid-OIDC spec or (c) eliminate the hard dependency on WebID

[bblfish]

Another problem is that the WebID draft is just a draft.

Well so is Solid-OIDC and most of the specs that are interesting. Usually when something is no longer a draft, it is because it has very wide adoption.

(a) change the WebID spec (b) change the Solid-OIDC spec or (c) eliminate the hard dependency on WebID

You opened an issue on the WebID repository just a couple of hours ago. That repository was opened to allow the spec to evolve to new requirements. I made a proposal as mentioned above. Perhaps if we wait for others to make suggestions on how to proceed you will be able to make a more informed decision.

[acoburn]

Another problem is that the WebID draft is just a draft.

Well so is Solid-OIDC

Indeed. Solid-OIDC is also actively moving toward a more stable form. We do not want it to always be a draft. Part of moving in that direction means resolving these sorts of long-standing issues.

You opened an issue on the WebID repository just a couple of hours ago.

True. But from the initial responses, I did not get the sense that the WebID specification will be changing any time soon. The specific concerns I raised were effectively discarded. That did not inspire much confidence in there being any changes. From what I can tell, the WebID draft has not changed since March 5, 2014.

Please remember: I am not suggesting that we exclude the use of WebID, rather that we not depend on it directly, as we currently do.

[bblfish]

Note that you can not generalise WebID to DIDs, because did is a URI schema that does not encompass http or https. You will need to have the disjoint union of WebID and DIDs if you want to be open to DIDs. Unless you want to move the OIDC protocol totally away from HTTP.

[acoburn]

I am not suggesting a generalization of WebID to include DIDs. You are correct that such a thing is not possible.

I am suggesting that Solid-OIDC identify agents with URIs that can be dereferenced as RDF documents. Examples of such URIs include both WebID and DID.

[acoburn]

For example, in the Solid Web Access Control specification draft, it makes reference to WebID without depending on it:

agent An agent is a person, social entity or software identified by a URI, e.g., a WebID denotes an agent [WEBID].

Solid-OIDC could do something similar, though I would also include DID as an example:

Agent An agent is a person, social entity or software identified by a URI, e.g., a DID or WebID can denote an agent.

Contrast that with the current text:

WebID as defined by [WebID] A WebID is a URI with an HTTP or HTTPS scheme which denotes an Agent (Person, Organization, Group, Device, etc.).

[bblfish]

a DID or WebID

yes, that is what I mean by disjoint union.

[acoburn]

yes, that is what I mean by disjoint union.

Exactly. And so long as Solid-OIDC requires WebID, it cannot support DID

[bblfish]

Ok, I am all for you supporting DIDs. But supporting DID does not solve your mime type problem with WebID.

[acoburn]

I am not suggesting that we replace WebID with DIDs. Indeed, that would not solve the problem.

Rather, I am suggesting that Solid-OIDC stay independent of all that. You can use a WebID or a DID or whatever comes next.

That would solve the mime type problem.