# W3C Solid Community Group: Authentication Panel

* Date: 2021-11-01T15:00:00Z
* Call: https://meet.jit.si/solid-authentication
* Chat: https://gitter.im/solid/authentication-panel
* Repository: https://github.com/solid/authentication-panel

## Present
* Barath
* elf Pavlik
* Aaron Coburn

---

## Announcements

### Meeting Recordings and Transcripts
* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
* Use panel chat and repository. Queue in call to talk.

### Participation and Code of Conduct
* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
* [Solid Code of Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md)
* If this is your first time, welcome! please introduce yourself.

### Scribes
* Aaron Coburn
* elf Pavlik

### Introductions
* name

---

## Agenda

* [ Clarify which issuers are implicitly trusted. #52 ](https://github.com/solid/solid-oidc/pull/52)
* Other specs and requirements on Client ID Document
* Spec annotations for tests
* [Clarifying specific areas of overlap with AuthZ #30](https://github.com/solid/solid-oidc/issues/30)

---

## Topics

### Open Pull Requests

#### [DPoP draft update](https://github.com/solid/solid-oidc/pull/53)

Merged

#### [Implicit Trust](https://github.com/solid/solid-oidc/pull/52)

* Aaron: historically we supported implicit trust in certain contexts. I'm concerned that it can lead to security holes. I would be ok with trust where the issuer and webid are exactly from the same domain. Subdomains can open a can of worms. It seams that people are ok with having only explicit trust. I would prefer to only have explicit trust.
* Barath: How does it work when user signs up with IdP they never heard of. And then use new solid provider they never heard of. When all different service providers are in place how implicit trust would work here?
* Aaron: If you have all those providers split up, it becomes easier because you have to use explicit trust. The question is how do you bootstrap all those services.
* Barath: I was conflating bootstrapping trust, where there can be implicit trust in infrastructure. For example in DNS.
* Aaron: If we were to separate those two, if we require explicit trust and document pattern for how bootstrapping works, they can later always decide to change their explicit trust. With implicit trust you can never revoke that.
* Pavlik: what was the proposal for handling domains in that PR?
* Aaron: the propsal suggests `foo.bar.example.com` trusts `bar.example.com` and `example.com` and `com`
* Pavlik: the risk is that the implicit trust of `jane.doe.example` implies a trust of `doe.example`
* Pavlik: I agree with this concern and will comment on the PR that we do not want the implicit trust of domains and subdomains
* Pavlik: What about the case of a WebID to be non-Public?
* Barath: That seems to violate the principles of Solid
* Pavlik: For me the components make the assumption that the document is public. A non-public document might use a `rdfs:seeAlso` [as in webid spec]. We seem to assume that WebID documents are public
* Aaron: If you don't make them public it may limit your ability to interact with the rest of solid.
* Pavlik: Should we require that WebID documents are public?
* Barath: There might be a way around this. We could designate a non-functional WebID (e.g., the anonymous WebID) but you are using VCs and trying to be anonymous, this might not break the whole ecosystem
* Aaron: I have another suggestion. There are two ways of representing WebID with # fragment or 303 redirect. Client can just read header of the WebID resource. In that case you don't need access to the document itself. If you were to go down that route. It could still work.
* Pavlik: we will want to adjust our language to be clear that if the document is not public, the header must be provided. If access control is set on that document, it seems reasonable to ask a server to support the extra link header.

ACTION: acoburn will follow up in issue about non-public WebID Profile documents
ACTION: pavlik will follow up in PR about implicit trust

### Other specs and requirements on Client ID Document

https://solid.github.io/solid-oidc/#clientids-document
> When a Client Identifier is dereferenced, the resource MUST be serialized as an application/ld+json document unless content negotiation requires a different outcome.

https://github.com/solid/data-interoperability-panel/issues/210#issuecomment-953401259
> This format has two advantages -- first, it allows apps to host static JSON-LD documents as part of their deployment. Many Solid apps are composed of static JavaScript, so this doesn't add a requirement for a content-negotiatable backend.

* Pavlik: at present, when the client id document MUST be serialized as JSON-LD. This implies that the server is required to support that. But that seems to contradict the possiblity of a static document.
* Aaron: Let's take example of server which doesn't do any content negotiation, it either ignores it or returns 406. Following HTTP spec. If it supports content negotiation it would only return one's it supports.
* Pavlik: we don't want to require turtle to support turtle variant? We currently have some work standardizing application webid document. We should be careful in coordinating with other specifications. That may complicate other specs that have other requirements. They may expect Turtle; otherwise they would need to support JSON-LD, too. At least interop spec
* Aaron: It goes to the question what Client ID Document is. For purpose of Solid-OIDC it's just structure to support login. We could overload it to be Application Profile. I would suggest that this would be different.
* Pavlik: but if we are denoting an application by an IRI, if we want to use the same IRI to denote the application across specifications, it's not so easy to say that there should just be a different document for the profile.
* Aaron: Solid protocol requires both Turtle and JSON-LD for resource. Client should be able to expect one or the other. I would like to know what are the specific limitations when those documents are not content negotiateable into turtle.
* Pavlik: protocol requires at least Turtle and JSON-LD. That allows a client to have both turtle and JSON-LD.
* Aaron: We are coming from two different directions, is client id document is in the storage or not. How you answer this question leads you in different directions. It's possible to have those identifiers hosted independently from app. One could have app registry where you would find app identifiers, there one would find `redicrect_uri` etc. This could lead to app registries etc.
* Pavlik: if the client_id document is hosted in the storage, we can't guarantee that JSON-LD is compacted with the specific context. The current defn. makes it _harder_ for that profile document to be in Solid Storage. What stops a person from putting this data in solid storage?
* Aaron: It's question of what is requirement on server side and expectation on client side. Hosting client documents might not be easiest thing to do. If you have public document in the pod and it can be content negotiated. The inrupt oidc server it will handle that.
* Pavlik: What if JSON-LD is expanded
* Aaron: If you know the context you can just parse it as JSON. If not you just parse it as full JSON-LD.
* Pavlik: in that case, the use of the specialized `@context` seems to be an optimization. I would like to wait for what the other panels require. It seems that a client can receive turtle or json-ld, in which case these profile documents could be hosted in solid storage. What would you think of including the SHOULD but also requiring JSON-LD and TURTLE?
* Aaron: I don't want to require Turtle support. It means that you have to put it on a server requiring content negotiation. We are not eliminating possibility. A lot of apps are static apps, as such content negotiable profile document can't have this document be in static storage.
* Pavlik: but we could build on the existing Solid protocol, which seems like a small requirement.
* Aaron: I would like to see more apps using this feature.
* Pavlik: we can defer until we have more feedback from the interop panel. I had initially assumed that we could rely on Turtle content negotiation. Can we agree that since we use the same identifier that we need to coordinate across the different specs/panels?
* Aaron: Yes we can agree on that.

### Spec annotations for tests

https://github.com/solid/specification-tests#specification-annotations

* Aaron: I started working on basic test suit. It all runs in a browser, you can identify IdP that you want to test. It runs the tests and generates report. Currently it's very initial. That structure looks very promissing. It would be useful to have more annotations. Right now I'm having to build out what this structure is and link to specific sections of the document. Once it's in position where is more presentable I'll make PR to public repo.
* Pavlik: as a related follow-up from a discussion from the notification panel, I'd like to try (as an experiment), I'd like to add specific identifiers, along with turtle annotations. That way, we can parse those requirements that way. How does that sound as a starting point?
* Aaron: that sounds like a good plan
* Pavlik: are any requirements missing some links (fragment identifiers)
* Aaron: Currently I'm not even linking to the spec. This week I'll be spending some time on it. I will see where we are lacking information.
* Pavlik: we will need to think about how granular the requirements are
* Aaron: I would like that one requirement results in one set of tests. Since Solid-OIDC builds on OIDC which builds on OAuth. There is a lot that's need to be setup up front.
* Pavlik: we can wait to follow up on annotations as the test suite needs them

### Clarifying specific areas of overlap with AuthZ

[Issue#30](https://github.com/solid/solid-oidc/issues/30)

* Deferred to next week

---

PROPOSAL: text

name: +1,0,-1

ACTION: text