# W3C Solid Community Group: WebID Profile

* Date: 2022-03-15T17:00:00Z
* Call: https://meet.jit.si/solid-profile
* Chat: https://gitter.im/solid/profile-spec
* Repository: https://github.com/solid/webid-profile

## Present

* Virginia Balseiro (VB)
* Jeff Zucker (JZ)
* Timea Turdean (TT)
* Sarven (SC)
* Tim (TBL)
* Henry Story (HS)

---

## 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.
* Join queue to talk.

### Participation and Code of Conduct

* [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome.
* If this is your first time, welcome! please introduce yourself.

### Scribes

* Sarven

---

## Topics

### Background & discussion with Henry on WebID

URL: https://webid.info/

WebID specifications: https://www.w3.org/2005/Incubator/webid/spec/

* HS: There is a figure with Tim.. typing authentication and access control. Tim was viewing WebID as being the keychain type of thing where these things come together. Well, you have WebID and ties to OpenID

* TBL: only the public part

* HS: We used to have the WebID tied to public key. There was a protocol that went with it. That's still valid as pepople are still using TLS but now people are moving to security vocabulary from JSON-LD folks. There is lots of things you can put with this WebID. You need to link to things tha ??? I'm keen on using keys. There are also questions about FOAF profiles and how people link to it. People also used VCARD around 2015.

* TBL: What we are tryin gto do is to standardise that.. some shapes of hte VCARD. Pronouns, languages and so on.

* HS: Is there a document you've been working on?

* JZ: We have notes: https://github.com/solid/webid-profile

* JZ: So far we've been dealing with discovery, how you get the various documents. We haven't quite tackled what's in the documents. Some servers.. WebID document.. some documents are not directly editable and points to other documents that can be edited. We're trying to determine how widely that's used.

* HS: Makes sense that some profiles and descriptions to be private - some flexibility

* TBL: I'd say another way: you can have a public profile - typically - and they might also have private profiles e.g., whistlel blowing or part of their 'normal' social activities, like randomly generated WebIDs. Avatars use in chats.. they don't have to be real. If you don't have a name or a picture then you / softare can't function well.

* HS: There is the user profile - that should be more or less standard and interoperable. Then there is the protocol part that I've alway sbeen interested in. If you want to be able to authenticated, you need a link to your WebID and public key. Slowly as these things become standard, you can manage them.

* TBL: We have a working system, they can log-in, and other people can find useful information e.g., language speak, and so it should be immediately useful. show a QR code to the hostess at a restaurant. They can just look at that without having to get a Solid account.

* HS: Sounds good. Good to separate from the WebID spec itself. It would make it impossible to finsih the WebID spec. If you have that elsewhere then we can move those decisions.

* TBL: The WebID spec should be the minimum. Anything to do with trusted log on things. Do you need to have a name?

* HS: It would be personal. WebID spec doesn't mention any of that. If yo uhave some authentication relations then you can explain the relationship. Perhaps that element should be in the spec.

* TBL: I think it should be in the spec too.

* TBL: Solid WebID profile spec. That's what everyone can get. It can require the function for authentication but not the person's name.

* HS: (perhaps for Sarven) the webID spec should authentication protocols that can be tied ot WebID e.g., oidcIssuer. And TLS is going out a little but we might want to list some of these general concepts when the specs reach maturity and they can evolve over time.

* TBL: Our priroity to document existing practice. Log in with OIDC not TLS. Can we point to the WebID spec and how that connects to the Profile spec?

* HS: Sounds like the WebID spec should point to the WebID Profile spec about that. All of that might be quite obvious to us but not everyone. Then paranoid crypto people don't like linking keys to profiles..

* TBL: In the Solid system, eg., SolidOS, we have things where you put information that are public and private, type indexes with standard format, associated with a project. So there is a standard way of saying where I have an address book.

* HS: That sounds very useful.

* TBL: The WebID and the WebID Profile spec are different but all the systems we are using is the same. so, the WebID spec is important but they also want to make sure that it is out there and it is defined in test cases and stuff.

* HS: That's a good plan to have these two movements. The WebID spec is nearly - it is just a definition of a URL pointing at an agent. This is actually philosophical logic. Got some improvements based on that. I think most important is done by people working with code/apps so we won't have discussions on doing it in 5 million different ways.

* TBL: People have been involved in the project - we decided to move from FOAF to VCARD, it was kind of a decision at MIT.. import/export VCARD stuff. It was important for the growing curve. And the groups of people you know in the VCARD.

* TBL: What we want to do in write the spec in one way - arbitrary decisions. Normally pulling other htings so we get the functionality ... show it is useful. Have analogy of going to a restaurant or chat...

* HS: You speak of FOAF. That is most important part of 'social'. Link to friends, and have a network effect. I've been looking at access control. Of course it gets big. Say you have a rule that says all my friend's of friends can get access. That would mean if someone logged in, they would have to - the guard would have to check many profiles. User agent can pass a little proof.

* TBL: Do you have proof carrying authentication? We did cwm proofs. We had a paper. It is good because the guard has a rule that can either be a foaf or a coupon from x, or big list of reasons why people are allowed in. The user has the trouble of findin that. The user program finds you as a foaf, then that's good. Here are two documents you need to show tha tyou are a foaf, and then if you find these docs, take them to the server and it can rapidly check.

* HS: Cuts the search space by thousands..

* TBL: More scalable.

* TBL: This is all rocket science.. meanwhile we are just doing the Solid Profile. What has to be in the WebID profile and how does that link to sameAs WebID.

* HS: Is there something I can do? Will help Sarven to write WebID spec. We are here to understand the aims of everybody.

* JZ: The doc you and SC are working on what must be said.. and our task is to what can be linked to that document. There are certain relationships, type indexes, seealsos, the app can know what to follow. It doesn' thave to follow forever. The more you can specify what has to do in that WebID doc, then we can say what can go in the other document.

* TBL: Why would the WebID spec use .. if the WebID spec is about the authn space, why would it use a particular vocab?

* SC: We have foaf:Agent and VCARD. We need to iron it out and specify it further.

* HS: we also used foaf:agent in the WAC spec

* TBL :Why do you have to tell .. foaf:Agent?

* HS: WebID is a URL that refers to a foaf:Agent.

* TBL: I want to question every triple you put in there.

* HS: We don't specify the subclass as long as foaf:Agent.

* SC: we do not know if foaf:agent was a hard requirement. WebID 1.0 should maybe not say anything about description of profile, it is only used in authentication (TLS)

* HS: The URL refers to the document and has to the person in the document. What's missing is a standard decsription. Perhaps what you want to do is a standard description.

* JZ: accountName was proposed but we thought nick could work. something that can be shown as what you are logging in/out. Sort of like a name without giving away.

* TBL: Is the idea that it should be nicks?

* JZ: They were proposing user@domain and use the short form. You can't really tell who the user is from the WebID. This would be the name for the IdP. Not sure if it is necessary.

* TBL: Everything needed for authentication should go in it.

* SC: I think from the WebID spec it should stay agnostic unless required. Required from a downstream spec -> solid is usying this authentication so it must exist (solid:oidcIssuer)

* HS: it could have a non-normative section but particularly common in RFC.

* JZ: Not necessary for computers but for the user - politeness. Not really at the same level as a solid:oidcIssuer

* HS: Perhaps put your ties to your WebID into your app. There might be need a keychain type of thing. If I have 2-3 WebIDs, and want my user interface to show me a fish on one, and another logo on the other. If I want to associate them..

* TBL: I have me with Solid purplel background on one and my other one ... to tell where I'm logged in from.

* HS: Nick is a useful relation.

* TBL: Maybe schema.org too.

* TBL: There is some form.. where if you are an agent, a VCARD Org or bot.. if Org, then you have an address book different sets of contacts. Solid project for example with different groups controlling them. Members of the group have different pods to do different things. Admins changes all the groups for example. You can construct things like we do on github or slack. using organisations / sub orgs, groups and different roles. That would allow us to implement different things. Facebook groups / google circles etc.. The interest thing: Github has organisations. We can make it general, so Solid Project would have SolidOS, whereas in github, then everyone is on the same level of org. It is quite exciting to use Solid to run the Solid project.

* HS: Solid is the future. Got some more funding to do more work on this stuff. Things are looking better. Trying to finish my Web server so I can use it myself with apps. For example, Henry Story says: https://github.com/co-operating-systems/Reactive-SoLiD/blob/work/src/main/scala/run/cosy/http/auth/Auth.md how to pass a foaf based authentication. Have to see how that fits with the work that was mentioned, PCA (proof carrying authentication). WebID CG is interested in JSON-LD.

* TBL: Most of our stuff is in Turtle.

* JZ: Software agent had to be JSON-LD but haven't heard that profile for a person or a org has to be JSON-LD.

* HS: Was it for Solid OIDC to identify a client, and to appeal to JSON people, so JSON-LD. I'm fine just don't want it to be every single format.

* JZ: My understanding is that.. we are not touching software agents, we are only focused on people.

* TBL: Was discussing wiht Sarven. If it is on a pod, to a certain extent, if it can be read-write, so profile has to be on a Solid pod so it need to support Patch as well. Need to do content negotiation. The compromise we came to was that give me either Turtle or JSON-LD. Both communities can use it. When you get a patch, then must be able to change it and write it back.. what's behind it: turtle or database or whatever we don't mind. we just want the functionality. if you don't provide to accept patches, then ... I can imagine WebID can end up where JSON-LD is provided where it just has your username.. the pointer to your solid profile on a pod. Potentially more than one pod. We have pointers between pods. The software can pull in different information from different pods.

* JZ: Document is on different servers for where one of them is writable. It is not necessarily on a pod.

* TBL: some gov can issue the id.

* TBL: henry, Working with Aaron?

* HS: I haven't too closely. Find Solid OIDC too inefficient. For me, Solid should be more efficient. Find foaf networks interesting. When I look at Solid OIDC, I see too many redirects.. but lots of stuff out there is using it.

* TBL: do the standard but also do the http signature.. or whatever sort of fast public/private key.. at a research level. in order to play.. is to have a level of in the code where you can switch between..

* HS: perhaps I should use existing code and hack into my system.

* TBL: Just port it over?

* HS: Possible. ScalaJS.. I should move that on my priority list. That'd be important to get that done. I can help.. I got more stability but haven't yet signed contract and things.. Trying to get my server and replace it with the one I've written. Then poeple can say what they'd like.

* TBL: run it with the test suite..

* HS: I have to run it again.

* TBL: solid OIDC is not expertise..

* HS: All code I'm using can be used by JS frameworks.. because Scala compiles to both.. but that's not the topic of this conversation. Havne't been introduced to Virginia and Timea.

* TT: I work at Inrupt and got introduced to Inrupt. I work with Virginia, and got introduced to WebID Profile spec working with Jeff.

* VB: I'm a software engineer at Inrupt. Found out about Solid when I joined.

* JZ: Any questions for Henry?

* TT: Find your points of views interesting - since I'm also new to the ecosystem I'm learning. I now learn about trusted graphs.

* TBL: Watch out for category theory? :P

* TT: Mostly in Java in the past 10 years. Coming from SW, RDF4J. About two years ago I tried ScalaJS.. interesting but it didn't stick. Now I do NodeJS.

* VB: Mostly JavaScript. Mostly frontend.

* HS: React mostly?

* VB: yes.

* HS: It was exciting but haven't used it beyond initial apps.. fetching/displaying foaf network in HTML. Interesting.

* TT: Community is broader than the ones you usually see.

* HS: If you want to really dive into.. a phD report, how webID ties to geopolitics and speech act. still a lot of work to do get a PhD out of it.. I wouldn't look at it that way. That's why TBL called the Web philosophical engineering.