ewingson/_webid_profile_panel_discussion_protocol_2022-1102_double_

## _webid_profile_panel_discussion_protocol_2022-1102_double_
# W3C Solid Community Group: WebID Profile

* Date: 2022-11-01T17:00:00Z
* Call: <https://meet.jit.si/solid-profile>
* Chat: <https://gitter.im/solid/webid-profile>
* Repository: <https://github.com/solid/webid-profile>

## Present

* [Virginia Balseiro](https://virginiabalseiro.com/#me)
* Jeff Zucker
* Samu Lang
* Aaron Coburn
* Daniel Bakas
* [Sarven Capadisli](https://csarven.ca/#i)
* Tim Berners-Lee
* Emelia Smith

---

## 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

* Virginia
* Sarven

### Introductions

* DB: Following Solid for last 5 years. Joining to listen/learn and offer help in any way. Student.

---

## Topics

### Meeting Time

* SC: Updated <https://github.com/solid/webid-profile/blob/main/README.md#participation> to include regular timeslot 16:00 UTC. Apparently today is an exception (17:00 UTC).

### Updates on prior ACTIONs and ongoing work

* VB: still working on use cases (#54 and #55) and trusted apps. Also working on #53 (considerations section).
* VB: Edited storage section and removed uses of 'pod'.
* VB: Related to above: <https://github.com/solid/webid-profile/issues/72>

* JZ: Working on an intro based on #52 -uses/functions/purposes of a profile

### PodSpaces WebIDs discussion

* TBL: Hard to keep track of Gitter discussions. Question for ESS team: the core issue is when we say WebID, we used it with 2 diff meanings.  OIDC context: thing you log in with. Traditionally: data about you on the web for things like your friends, photos, etc. Social WebID. authentication got added, public key to prove you are who you are. Social network: people are in a group because their online persona ???. WebID-SolidOIDC: we need to put a link in it, only technical/authn information, otherwise not secure.
* AC: Good summary, captures evolution of WebID Profile. Even under WebID-TLS, we see the same issue: mixing profile information (bname, avatar) with security information. If any app can write to WebID profile with WebID-TLS, any app can add a second public key, and if a malicious actor controls that key, they have access to your data. Same argument re: separating authentication (sec info) and public info (profile data). Conversation thus far has been: everything needs to be WebID (one for security-related, one for non). It is possible to rethink the use of WbID in Solid-OIDC. We can back away from WebID. Will take work and time.
* TBL: You mean the word WebID in the spec?
* AC: Yes. We can use DIDs, or some other thing, for authn. As long as we can separate security from non-security info. Entirely possible to have different terms. Right now they are both WebID which leadas to confusion.
* TBL: If we have two separate things and link, this link ??? If A links to B, but indirectly, you log in with A but then it shows you're B, B 'being the person with the profile data, and maybe security things, like a signed proof that I'm a member of something. If we have A and B, if I put one of these into an ACL, do I drag in A or B? I imagine it's A, because that's the ID. The QR code in your phone you pass around, that is you. At the moment in NSS that's very easy: I put your WebID into an ACL. Every representation of you in the system has your WebID behind it. With the indirection, things break. If I look at it and have a piece of RDF with solid-oidc pointer, or primaryTopic, then that is one possible design, but then that needs to build into anything that looks at an ID. Two things being the same has problems, but them being different has problems too. Because if anything that follows A gets redirected to B, then ??? security concern: anything can be pointed to B and impersonate the person described by B. ??? Everytime somebody does a lookup of A they're hitting the IDP, authn server, instead of Pod.
* ES: When you say HTTP client hitting IDP, you mean going directly to the IDP ???
* TBL: ??? hopefully they will get ???
* ES: if I put my WebID on the browser and I want some UI to be rendered, would it not be ok to have a predicate that says "render WebID with this UI"? Recommend that if that predicate is present, redirect to viewer.
* TBL: On current solid pods, anytime a user puts in any URL in RDF they get a quick UI ??? person running server they choose a data browser.
* SL: Going back a bit. TBL spoke about two usages of WebID term. ESS at the moment with current choices does not ??? the WebID profile document which adheres tol ??? and solid-oidc
* TBL: Solid-OIDc WebID. Not social profile.
* SL: Any kind of WebID profile you choose you can store in a ESS pod. Nothing stopping it. However, there are also cases of identity management, where for many reasons we don't want users to have the same kind of access control to their webid profile that they have to rest of pod. That is because operators of solid servers have different reqs. Choices of ESS don't stop any use cases. Just enable another one. The one where WebID Profile is used for identity and less social. More security/authn. This case is also important. Different wats of thinking about WebIDs.
* AC: Notion of WebID Profile being in multiple locations / bfiurcation / multiplication. In contrast with a singular one. Even in ESS model you can have a single WebID document (social info). You can have that in the one WebID profile. Not in your Pod or storage but you can.
* TBL: The way Solid ecosystem is extensible is that each person comes along, like Noel made a recipe app, adds a type index, but you can imagine if I decide publishing spoken languages important, if apps can pick up that from WebIDs, that's valuable. So It is useful to add other stuff into WebID. We need to be able to use a Solid PATCH.
* SL: You can make an HTTP PATCH.
* TBL: ???
* SL: The WebID service, component of ESS which handles this, is a pure REST API.
* TBL: Is it complete from the Solid perspective?
* SL: LOL. It is an HTTP API.
* JZ: What app can PATCH against that WebID Profile?
* SL: ??? reason for separation: allow operators to choose an app.
* TBL: Could we persuade those operators to include type indexes, etc.?Basic stuff like avatar, name.
* SL: Nothing in current ESS that prevents that.
* TBL: ???
* JZ: Problem: seeAlso. If we don;t want seeAlso leading to neverending seeAlsos, we need to have ??? if we can't ??
* AC: Privacy: nice to require things like name/profile, but certain contexts there are issues with kinds of issues being required.
* TBL: Absolutely.
* ES: There are valid use cases for not disclosing anything about actual identity. Ex: not wanting people to know my identity. Separate WebID than IRL WebID. If we mandate in a spec that WebID profile document (ESS WebID) must contain name, avatar, then we are in a weird position.
* TBL: Solid has always supported both use cases: person wanting everything public, and person wanting to be extremely private. Extreme case of someone just having a one-time-use WebID for something, e.g.: whistleblowing. Not worried about having their identity mistaken. There are other ways of handling this.
* SC: I want to know if WebID is part of a solid storage, is the URI in the same space as solid storage?
* SL: Not in same namespace.
* SC: Is it a member, container, discoverable from storage?
* TBL: URLs have nothing to do with each other.
* SC: Checking to know if Solid Protocol, is responding when derferencing WebID.
* AC: No it is not, but what changes if it were? Only change you receive an Accept Patch resopnse header.
* SC: If passes comformance reqs, that's effectively Solid.
* AC: It is Solid with a lot of contraints. Typical user has no access to a GET on root container, so root container would list all the users, we don't want that, so we need to make sure those requests are blocked. You can create resources in the same way you do in Solid Protiocoal, you can creat containers, constraints that are possioble with Solid protocol. Nothing violates the Solid protocol.
* DB: there are two avenues: one is security, where there's the concert that if a req is made to WebID profile (PATCH, etc) data that is for authn purposes is exposed to that req. The issue with that is buy taking data out of that doc, you can assign diff access to each type of data (sec vs profile/dscription data)
* DB: E brings up expression. How would I like to express my discoverable data. Also part of Solid. Contextual data as well. Not only what Tim says about minimal profile. You would also need to have name/work.. to have that in the Profile Document could be difficult. I just wanted to offer this separation between security, authoziation, and expression., You could perhaps solve different avenues at the same time.
* TBL: I don't think we need to make you have one login and several profiles. If you want to have different personas you should have different WebIDs. Should have separate logins/delegates/access.
* TBL: If the ESS team can do this provide the WebID document is a real Solid document, we can put that in a way that protects the core security information than why cnat you do that also with my profile in the middle of the pod too. you can proxy it / separate it / different machines. No reason why they need to be separate.
* TBL: What about domain names. The actual reason is: Solid would be insecure if ??? we need to bring aaron.name to the service and WebID needs to be aaron.name go through ??? yourself wil be aaron.name and you get thte name and picture. Your blog won't have a ??? in it. Your recipe/connections will have x.y.z/uuid/aaron or something. If you bring your own domain name and human-readable names, then it is nice to have all your stuff on the same domain.
* SL: That's still possible. It just facilitates the alternative for those that need it.
* AC: Also underestimates managing the TLS certificate. If JZ has a domain name at jz.com and basically needs to give us a certificate to manage. In certain cases that can be done reasonably well but when it gets into renewals or delegation there is a lot of complexity there. So rather than saying bring your own domain name - which is great - but tremendous amount of infrastructure needed to that in a secure way.
* TBL: At the moment.. you have to go to gandi. But if foobar bought gandi, ??? when someone logs in the first time and they mind a public key pair for the identity, then from then on ... there is a lot of bureaucracy to login to gandi. but not more than signing someone's VC. creating and signing keys. yes, right now it is but we should start another track in the CG to allow people to work with their domains. We have onboarding procedures. Need to think about how to make it as easy as .. coming to get an account. Special domain names where we have arrangements with people.
* JZ: Where does that leave us.
* VB: Do we need another session?
* TBL: Two ways to go. 1) accept the way it is and all apps have to adapt 2) push back on that none of the answers convinced us that this is needed. So, putting an nginx.. you could make it look like one single pod. Having a solid pod would be glorious to the user - something they are invested in with their name. Of their blogs and ids all have URLs in their domain name they can remember. Delivering value to the user.
* VB: +1
* ES: WebID Profile cannot mandate but can recommend as guideline/consideration. should have. To specify in the spec some way. We recommend ... but it may not be. You need to build your app
* VB: That's in considerations for most of the spec. That's not an issue. It is more of a matter of where is that info. Whether that is a huge burden on apps or new way of working or is there a better solution for keeping documents as one. It is not that we are worried about whether name/avatar are there. We expect the UI thing where it is a separate discussion where you don't have certain data. Especially when an app tries to discover the type indexes amoing other important things that are in use and work.
* ES: Also an argument made where apps shouldn't be writing to WebID profile just because it can that's the right place to put the data. Some WebIDs.
* TBL: Reasonable to put in different places but ... dereferencing your WebID happens all the time.
* VB: Consideration but not the main issue. The problem is that apps need to write to WebID. They shouldn't just dump everything there because they can - that's a separate topic: UI/UX best practices. What we are saying is that where there are legitimate cases where apps need to write stuff to WebID because they need to be discoverable and they are starting from the WebID.
* DB: Agreed. But also share TBL's interest in what we are discussing. Would it be useful to formulate concrete questions where everyone has been talking about. What is currently discussed and what will be. Bring these concrete questions to next meeting so that we all know what we are talking about.
* TBL: Another to come back is with scenarios. Of all of the things in the design space we are focusing on possible outcomes where we push back with URL be the same - get the same security - and the other is a limited amount of ??? question is we change the software and be aware of webid and profile being separate things. What happen if we do solution X or Y? What does involve changing?
* JZ: Main issue is it'd be nicer to have one document. App devs can go into one place and look for things. In addition to TBL's reasons, I'd like that to work, I wonder what would be acceptable to have certain parts of a profile not be in a person's control, go through some server app, profile needs a pointer to type index and other things, anything else goes through the provider. But that means app don't control the profile.
* ES: Few things: 1) topic of visiting WebID in the browser and what you see. NSS/CSS SolidOS. ESS: user sees a rendered version of the content of the WebID. We need a separate specification to define this behavior in the browser. 2) no server supports bring your own domain name. that needs further specification. important to note that needs to change access tokens you receive because they include WebID as subject. 3) current no access control mechanism that specifies triple level access. can a server block a patch to oidc-issuer?
* DB: Question seems to be whether main profile deferencing WebID should be easy for devs to r
* VB: Convoluted for app developer. To fix it, what you have to do is need to introduce concept of another document that is the "source of truth" for certain things / not random data but it is also discovery data. preferences/indexes, and how to discover that. it becomes inefficient. what we are trying to see is how to make that easier. pointing to one document.
* DB: I didn't know there was a triple-level ..
* TBL: There isn't.
* DB: If you wanted to protect a certain triple, you need to protect the document.
* TBL: Right.
* DB: What I gather is for the current state and not for the near future? In that sense, right now if you want to have the descriptive data. How could apps can easily discover the data re VB's point.
* JZ: Since the server has right to control the issuer, it can protect that. It is not an access control thing.
* DB: It is hard for us to agree whether should be or not in the main profile without the priority. Perhaps we can discuss priority of one data over another. Some stuff in the main document, and the other perhaps pointed from there. If we are going to request the WebID profile every time, if you have a couple..
* SC: Social profile. Social from the start. You read and write your personal data to it. WebID is used for different reasons, not just authn.
* SC: Server can reject a write request for any reason and indicate in the response. Some servers might let you write certain statements, some may not. Solid-OIDC is one of the cases.
* SC: Human-readable - solved problem. HTML+RDFa. Not a requirement (only Turtle is). Majority of the web is publishing homepages, contact info, allowing people to move to a Solid server you cannot tell them they cannot have a homepage. These are developer problems being passed onto the user. By making those decisions we are dismissing the most widely deployed thing on the Web (homepages, / --> container).
* SC: Re: approaches whether we should stand in our position. All is possible and we shouldn't prevent. But if we're designing it so that it is what's possible at the expense of developing something simple, we're complicating in order to allow only certain people to develop certain servers. It is already difficult for people to rent a domain name and find a host and publish something. If we're making that more complicated by saying "your IDP is in this server, you need an app for that and your Profile is in another and you need another one". I haven't seen apps doing these, so it is certainly possible, but I don't think the avg person will do this. Decisions that we're making ??? we shouldn't get the authors to be happy. We need to design for those people that are lower in priority: the user. and work through the technicalities. If devs find it hard to deploy a server and allow a user to have a single document, why is that problem passed on to the user?
* VB: +1
* SC: Owning and controlling. "You kinda own it and not". This discussion is because of solid-oidc. If we're writing this spec from the time of WebID-TLS we would not be discussing separate IDP, we would be writing a single resource. Documents should describe themselves: <https://www.w3.org/2001/tag/doc/selfDescribingDocuments> as much as possible. Asking the user/app to go and fetch multiple requests to update a profile and identity at different resources. All of these decisions are doing a lot of architectural astronomy. Complicating what is already complicated.
* VB: +1
* TBL: We should not be doing arch. astronomy. We have code in SolidOS which works. and puts things in your profile. First job is documenting that. so that others can use it. and do the same thing. we need to do that with the profile. the way SolidOS is written is along the spirit of what SC says. Designed for actually using/doing basic things.
* TBL: Focus on progress made on SolidOS and writing that as specs. Works with NSS/CSS. Doesn't work with ESS. What is the smallest change that will make it work?
* ES: id.inrupt.com is not a Solid server. uses not even authn from using ask. diff level.
* SC: I understood from Aaron that server conforms to solid protocol...
* TBL: Not convinced. that it does everything.
* ES: Current WebID spec doesn't require it to be on a solid server. just that it must be able to be dereferences and turtle. nothing about it being a solid resource.
* SC: Of course not, because WebID can be used in different ways.
	# W3C Solid Community Group: WebID Profile

	* Date: 2022-11-01T17:00:00Z
	* Call: <https://meet.jit.si/solid-profile>
	* Chat: <https://gitter.im/solid/webid-profile>
	* Repository: <https://github.com/solid/webid-profile>

	## Present

	* [Virginia Balseiro](https://virginiabalseiro.com/#me)
	* Jeff Zucker
	* Samu Lang
	* Aaron Coburn
	* Daniel Bakas
	* [Sarven Capadisli](https://csarven.ca/#i)
	* Tim Berners-Lee
	* Emelia Smith

	---

	## 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

	* Virginia
	* Sarven

	### Introductions

	* DB: Following Solid for last 5 years. Joining to listen/learn and offer help in any way. Student.

	---

	## Topics

	### Meeting Time

	* SC: Updated <https://github.com/solid/webid-profile/blob/main/README.md#participation> to include regular timeslot 16:00 UTC. Apparently today is an exception (17:00 UTC).

	### Updates on prior ACTIONs and ongoing work

	* VB: still working on use cases (#54 and #55) and trusted apps. Also working on #53 (considerations section).
	* VB: Edited storage section and removed uses of 'pod'.
	* VB: Related to above: <https://github.com/solid/webid-profile/issues/72>

	* JZ: Working on an intro based on #52 -uses/functions/purposes of a profile

	### PodSpaces WebIDs discussion

	* TBL: Hard to keep track of Gitter discussions. Question for ESS team: the core issue is when we say WebID, we used it with 2 diff meanings. OIDC context: thing you log in with. Traditionally: data about you on the web for things like your friends, photos, etc. Social WebID. authentication got added, public key to prove you are who you are. Social network: people are in a group because their online persona ???. WebID-SolidOIDC: we need to put a link in it, only technical/authn information, otherwise not secure.
	* AC: Good summary, captures evolution of WebID Profile. Even under WebID-TLS, we see the same issue: mixing profile information (bname, avatar) with security information. If any app can write to WebID profile with WebID-TLS, any app can add a second public key, and if a malicious actor controls that key, they have access to your data. Same argument re: separating authentication (sec info) and public info (profile data). Conversation thus far has been: everything needs to be WebID (one for security-related, one for non). It is possible to rethink the use of WbID in Solid-OIDC. We can back away from WebID. Will take work and time.
	* TBL: You mean the word WebID in the spec?
	* AC: Yes. We can use DIDs, or some other thing, for authn. As long as we can separate security from non-security info. Entirely possible to have different terms. Right now they are both WebID which leadas to confusion.
	* TBL: If we have two separate things and link, this link ??? If A links to B, but indirectly, you log in with A but then it shows you're B, B 'being the person with the profile data, and maybe security things, like a signed proof that I'm a member of something. If we have A and B, if I put one of these into an ACL, do I drag in A or B? I imagine it's A, because that's the ID. The QR code in your phone you pass around, that is you. At the moment in NSS that's very easy: I put your WebID into an ACL. Every representation of you in the system has your WebID behind it. With the indirection, things break. If I look at it and have a piece of RDF with solid-oidc pointer, or primaryTopic, then that is one possible design, but then that needs to build into anything that looks at an ID. Two things being the same has problems, but them being different has problems too. Because if anything that follows A gets redirected to B, then ??? security concern: anything can be pointed to B and impersonate the person described by B. ??? Everytime somebody does a lookup of A they're hitting the IDP, authn server, instead of Pod.
	* ES: When you say HTTP client hitting IDP, you mean going directly to the IDP ???
	* TBL: ??? hopefully they will get ???
	* ES: if I put my WebID on the browser and I want some UI to be rendered, would it not be ok to have a predicate that says "render WebID with this UI"? Recommend that if that predicate is present, redirect to viewer.
	* TBL: On current solid pods, anytime a user puts in any URL in RDF they get a quick UI ??? person running server they choose a data browser.
	* SL: Going back a bit. TBL spoke about two usages of WebID term. ESS at the moment with current choices does not ??? the WebID profile document which adheres tol ??? and solid-oidc
	* TBL: Solid-OIDc WebID. Not social profile.
	* SL: Any kind of WebID profile you choose you can store in a ESS pod. Nothing stopping it. However, there are also cases of identity management, where for many reasons we don't want users to have the same kind of access control to their webid profile that they have to rest of pod. That is because operators of solid servers have different reqs. Choices of ESS don't stop any use cases. Just enable another one. The one where WebID Profile is used for identity and less social. More security/authn. This case is also important. Different wats of thinking about WebIDs.
	* AC: Notion of WebID Profile being in multiple locations / bfiurcation / multiplication. In contrast with a singular one. Even in ESS model you can have a single WebID document (social info). You can have that in the one WebID profile. Not in your Pod or storage but you can.
	* TBL: The way Solid ecosystem is extensible is that each person comes along, like Noel made a recipe app, adds a type index, but you can imagine if I decide publishing spoken languages important, if apps can pick up that from WebIDs, that's valuable. So It is useful to add other stuff into WebID. We need to be able to use a Solid PATCH.
	* SL: You can make an HTTP PATCH.
	* TBL: ???
	* SL: The WebID service, component of ESS which handles this, is a pure REST API.
	* TBL: Is it complete from the Solid perspective?
	* SL: LOL. It is an HTTP API.
	* JZ: What app can PATCH against that WebID Profile?
	* SL: ??? reason for separation: allow operators to choose an app.
	* TBL: Could we persuade those operators to include type indexes, etc.?Basic stuff like avatar, name.
	* SL: Nothing in current ESS that prevents that.
	* TBL: ???
	* JZ: Problem: seeAlso. If we don;t want seeAlso leading to neverending seeAlsos, we need to have ??? if we can't ??
	* AC: Privacy: nice to require things like name/profile, but certain contexts there are issues with kinds of issues being required.
	* TBL: Absolutely.
	* ES: There are valid use cases for not disclosing anything about actual identity. Ex: not wanting people to know my identity. Separate WebID than IRL WebID. If we mandate in a spec that WebID profile document (ESS WebID) must contain name, avatar, then we are in a weird position.
	* TBL: Solid has always supported both use cases: person wanting everything public, and person wanting to be extremely private. Extreme case of someone just having a one-time-use WebID for something, e.g.: whistleblowing. Not worried about having their identity mistaken. There are other ways of handling this.
	* SC: I want to know if WebID is part of a solid storage, is the URI in the same space as solid storage?
	* SL: Not in same namespace.
	* SC: Is it a member, container, discoverable from storage?
	* TBL: URLs have nothing to do with each other.
	* SC: Checking to know if Solid Protocol, is responding when derferencing WebID.
	* AC: No it is not, but what changes if it were? Only change you receive an Accept Patch resopnse header.
	* SC: If passes comformance reqs, that's effectively Solid.
	* AC: It is Solid with a lot of contraints. Typical user has no access to a GET on root container, so root container would list all the users, we don't want that, so we need to make sure those requests are blocked. You can create resources in the same way you do in Solid Protiocoal, you can creat containers, constraints that are possioble with Solid protocol. Nothing violates the Solid protocol.
	* DB: there are two avenues: one is security, where there's the concert that if a req is made to WebID profile (PATCH, etc) data that is for authn purposes is exposed to that req. The issue with that is buy taking data out of that doc, you can assign diff access to each type of data (sec vs profile/dscription data)
	* DB: E brings up expression. How would I like to express my discoverable data. Also part of Solid. Contextual data as well. Not only what Tim says about minimal profile. You would also need to have name/work.. to have that in the Profile Document could be difficult. I just wanted to offer this separation between security, authoziation, and expression., You could perhaps solve different avenues at the same time.
	* TBL: I don't think we need to make you have one login and several profiles. If you want to have different personas you should have different WebIDs. Should have separate logins/delegates/access.
	* TBL: If the ESS team can do this provide the WebID document is a real Solid document, we can put that in a way that protects the core security information than why cnat you do that also with my profile in the middle of the pod too. you can proxy it / separate it / different machines. No reason why they need to be separate.
	* TBL: What about domain names. The actual reason is: Solid would be insecure if ??? we need to bring aaron.name to the service and WebID needs to be aaron.name go through ??? yourself wil be aaron.name and you get thte name and picture. Your blog won't have a ??? in it. Your recipe/connections will have x.y.z/uuid/aaron or something. If you bring your own domain name and human-readable names, then it is nice to have all your stuff on the same domain.
	* SL: That's still possible. It just facilitates the alternative for those that need it.
	* AC: Also underestimates managing the TLS certificate. If JZ has a domain name at jz.com and basically needs to give us a certificate to manage. In certain cases that can be done reasonably well but when it gets into renewals or delegation there is a lot of complexity there. So rather than saying bring your own domain name - which is great - but tremendous amount of infrastructure needed to that in a secure way.
	* TBL: At the moment.. you have to go to gandi. But if foobar bought gandi, ??? when someone logs in the first time and they mind a public key pair for the identity, then from then on ... there is a lot of bureaucracy to login to gandi. but not more than signing someone's VC. creating and signing keys. yes, right now it is but we should start another track in the CG to allow people to work with their domains. We have onboarding procedures. Need to think about how to make it as easy as .. coming to get an account. Special domain names where we have arrangements with people.
	* JZ: Where does that leave us.
	* VB: Do we need another session?
	* TBL: Two ways to go. 1) accept the way it is and all apps have to adapt 2) push back on that none of the answers convinced us that this is needed. So, putting an nginx.. you could make it look like one single pod. Having a solid pod would be glorious to the user - something they are invested in with their name. Of their blogs and ids all have URLs in their domain name they can remember. Delivering value to the user.
	* VB: +1
	* ES: WebID Profile cannot mandate but can recommend as guideline/consideration. should have. To specify in the spec some way. We recommend ... but it may not be. You need to build your app
	* VB: That's in considerations for most of the spec. That's not an issue. It is more of a matter of where is that info. Whether that is a huge burden on apps or new way of working or is there a better solution for keeping documents as one. It is not that we are worried about whether name/avatar are there. We expect the UI thing where it is a separate discussion where you don't have certain data. Especially when an app tries to discover the type indexes amoing other important things that are in use and work.
	* ES: Also an argument made where apps shouldn't be writing to WebID profile just because it can that's the right place to put the data. Some WebIDs.
	* TBL: Reasonable to put in different places but ... dereferencing your WebID happens all the time.
	* VB: Consideration but not the main issue. The problem is that apps need to write to WebID. They shouldn't just dump everything there because they can - that's a separate topic: UI/UX best practices. What we are saying is that where there are legitimate cases where apps need to write stuff to WebID because they need to be discoverable and they are starting from the WebID.
	* DB: Agreed. But also share TBL's interest in what we are discussing. Would it be useful to formulate concrete questions where everyone has been talking about. What is currently discussed and what will be. Bring these concrete questions to next meeting so that we all know what we are talking about.
	* TBL: Another to come back is with scenarios. Of all of the things in the design space we are focusing on possible outcomes where we push back with URL be the same - get the same security - and the other is a limited amount of ??? question is we change the software and be aware of webid and profile being separate things. What happen if we do solution X or Y? What does involve changing?
	* JZ: Main issue is it'd be nicer to have one document. App devs can go into one place and look for things. In addition to TBL's reasons, I'd like that to work, I wonder what would be acceptable to have certain parts of a profile not be in a person's control, go through some server app, profile needs a pointer to type index and other things, anything else goes through the provider. But that means app don't control the profile.
	* ES: Few things: 1) topic of visiting WebID in the browser and what you see. NSS/CSS SolidOS. ESS: user sees a rendered version of the content of the WebID. We need a separate specification to define this behavior in the browser. 2) no server supports bring your own domain name. that needs further specification. important to note that needs to change access tokens you receive because they include WebID as subject. 3) current no access control mechanism that specifies triple level access. can a server block a patch to oidc-issuer?
	* DB: Question seems to be whether main profile deferencing WebID should be easy for devs to r
	* VB: Convoluted for app developer. To fix it, what you have to do is need to introduce concept of another document that is the "source of truth" for certain things / not random data but it is also discovery data. preferences/indexes, and how to discover that. it becomes inefficient. what we are trying to see is how to make that easier. pointing to one document.
	* DB: I didn't know there was a triple-level ..
	* TBL: There isn't.
	* DB: If you wanted to protect a certain triple, you need to protect the document.
	* TBL: Right.
	* DB: What I gather is for the current state and not for the near future? In that sense, right now if you want to have the descriptive data. How could apps can easily discover the data re VB's point.
	* JZ: Since the server has right to control the issuer, it can protect that. It is not an access control thing.
	* DB: It is hard for us to agree whether should be or not in the main profile without the priority. Perhaps we can discuss priority of one data over another. Some stuff in the main document, and the other perhaps pointed from there. If we are going to request the WebID profile every time, if you have a couple..
	* SC: Social profile. Social from the start. You read and write your personal data to it. WebID is used for different reasons, not just authn.
	* SC: Server can reject a write request for any reason and indicate in the response. Some servers might let you write certain statements, some may not. Solid-OIDC is one of the cases.
	* SC: Human-readable - solved problem. HTML+RDFa. Not a requirement (only Turtle is). Majority of the web is publishing homepages, contact info, allowing people to move to a Solid server you cannot tell them they cannot have a homepage. These are developer problems being passed onto the user. By making those decisions we are dismissing the most widely deployed thing on the Web (homepages, / --> container).
	* SC: Re: approaches whether we should stand in our position. All is possible and we shouldn't prevent. But if we're designing it so that it is what's possible at the expense of developing something simple, we're complicating in order to allow only certain people to develop certain servers. It is already difficult for people to rent a domain name and find a host and publish something. If we're making that more complicated by saying "your IDP is in this server, you need an app for that and your Profile is in another and you need another one". I haven't seen apps doing these, so it is certainly possible, but I don't think the avg person will do this. Decisions that we're making ??? we shouldn't get the authors to be happy. We need to design for those people that are lower in priority: the user. and work through the technicalities. If devs find it hard to deploy a server and allow a user to have a single document, why is that problem passed on to the user?
	* VB: +1
	* SC: Owning and controlling. "You kinda own it and not". This discussion is because of solid-oidc. If we're writing this spec from the time of WebID-TLS we would not be discussing separate IDP, we would be writing a single resource. Documents should describe themselves: <https://www.w3.org/2001/tag/doc/selfDescribingDocuments> as much as possible. Asking the user/app to go and fetch multiple requests to update a profile and identity at different resources. All of these decisions are doing a lot of architectural astronomy. Complicating what is already complicated.
	* VB: +1
	* TBL: We should not be doing arch. astronomy. We have code in SolidOS which works. and puts things in your profile. First job is documenting that. so that others can use it. and do the same thing. we need to do that with the profile. the way SolidOS is written is along the spirit of what SC says. Designed for actually using/doing basic things.
	* TBL: Focus on progress made on SolidOS and writing that as specs. Works with NSS/CSS. Doesn't work with ESS. What is the smallest change that will make it work?
	* ES: id.inrupt.com is not a Solid server. uses not even authn from using ask. diff level.
	* SC: I understood from Aaron that server conforms to solid protocol...
	* TBL: Not convinced. that it does everything.
	* ES: Current WebID spec doesn't require it to be on a solid server. just that it must be able to be dereferences and turtle. nothing about it being a solid resource.
	* SC: Of course not, because WebID can be used in different ways.