Skip to content

Latest commit

 

History

History
142 lines (108 loc) · 11.1 KB

2023-06-07.md

File metadata and controls

142 lines (108 loc) · 11.1 KB

W3C Solid Community Group: Weekly

Present

Announcements

Meeting Guidelines

  • W3C Solid Community Group Calendar.
  • W3C Solid Community Group Meeting Guidelines.
  • 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.
  • Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed.

Participation and Code of Conduct

Scribes

  • Virginia Balseiro

Introductions

Topics

Add 2023-05-25 agenda and minutes

URL: #527

  • SC: No minutes are provided, and if the meeting was informal, I suggest closing this as meeting cancelled.
  • eP: What does informal mean? No proposals or resolutions during the meeting, we discussed
  • SC: Since there are no minutes, there is nothing captured. If you want to make a suggestion to PR saying which topics were discussed and who was present, we can merge. Minutes should help those who cannot attend.
  • eP: We can close. Follow up will be in issues. Topics were Issue #525 and JSON-LD context for Solid Notifications.

ACTION: SC to close.

W3C TPAC 2023

URL: https://www.w3.org/2023/09/TPAC/

  • SC: Will anyone be in person at TPAC 2023?
  • SC: WIP TPAC 2023 - Group schedule is posted. Solid CG is on row 70 in the spreadsheet.

WIP Implementation Feedback

  • SC: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome.

HTTPSig Auth Demo

  • LD: What' the status of HttpSig specification?
  • HS: HTTP Signatures in being developed in the IETF HTTPBis group. The authors were in last-call in September at version 13. The received enough feedback to get them to version 17 in the meantime. But it is close to finished. HTTPSig is a lot more Solid now.
  • HS: My implementation of httpSig is on github. It is written in Scala that compiles to JavaScript, so that it can be used on the client and on the server. (It would need work for nodeJS.)
  • LD: Is it for any authenticated agent? ACLs working for keyid? See it working with WebID?
  • HS: It fits in nicely with other HTTP auth schemes. A server could support both HTTP Sig, OIDC, and/or passwords, too (and even WebID-TLS). The client should have a Solid Wallet (an EU project) with a number of credentials for the user (passwords, keys, etc.). It should be able to select which of the ACL descriptions fit which keys and decide which is best for the authentication needs of the user.
  • TBL: Good demo. I suppose ??? How much would it take for CSS to use it? You got Scala→JavaScript. CSS needs JS. Is there a test suite?
  • HS: HttpSig depends on RFC 8941: Structured Header Fields for which I have an implementation rfc8941.scala, and a lot of detailed tests. That is used by what I call ietfSig (as the RFC does not yet have a number), and there are also a lot of tests for the HTTPSig, which I tried to keep generic so that they can work across platforms. (The current platforms are akka (Java and http4s (Java and JS)).
  • TBL: How many lines of code is this? Implementation code to convert to JavaScript.
  • HS: Scala-JS allows one to wrap pure JS libs, but also to write interfaces to make the libs written easy to use by JS developers. I am not a JS or CSS guru, so that side of things needs to be refined. If you send me someone that's a JavaScript developer, we can find the right people to see how much of the code I have can be used by CSS. I don't know CSS that well. I know people that would know how to bridge that gap to do it. I'd for sure be happy with more people using and maintaining the code.
  • SC: One of the most important things for this group is how HTTPSig specification advances. Will you be dedicating time to continue work on it? Important for implementations to use most current.
  • HS: I now have an implementation and experience. Definitely want to finish this now. I have a milestone on the EU project to do that. The latest version is on the sigUpdate branch of my clone of the authentication-panel repo.
  • SC: Feel free to bring updates on HTTPSig to the group.
  • TBL: Hopefully the WAC files shouldn't change, e.g., Groups. The modes like RWA. Useful for making this change, the way you make authenticate, and we can plug in HTTPSigs and keep everything else the same.
  • eP: often the user and app have their own WebID, and client has client ID. Each WebID has its own possible keys. In your case, is the private key the client's or the user's?
  • HS: working on a project called Solid Wallet, which should work in the client or as a proxy on the Solid-Pod. It should allow you to have your keys securely on your pod, protected so only the wallet (a trusted app) can access them, keep them in a safe place, and sign requests on your behalf. So the Wallet signs requests on your behalf, and so the idea is that this identifies the user. HS: Oh it looks like I forgot to record my screen. Luckily I guess the presentation was recorded on your side. SC: Ah no. We also forgot to do that! Sorry. HS: No problem. I'll make a screen cast after the talk. (Later Henry posted a link to a recording he put up that recapitulated the demo given that day @bblfish Tweet 10:48 PM · Jun 7, 2023. A YouTube upload is not yet ready)

Compatibility with existing implementations

URL: solid/solid-wg-charter#31

  • SC: Any objections to keeping the paragraph in?
  • SC: No objections.

ACTION: SC to close the issue and reflect group consensus.

Revise scope and out-of-scope

URL: solid/solid-wg-charter#38

  • SC: Resolves solid/solid-wg-charter#9
  • SC: We have some agreement in the PR but there's a bit of paraphrasing we need to be careful with. I do want to wrap up the PR, but if we can try to integrate changes that would clarify. Any objections to merging this PR?
  • ML: PAC wanted to answer but not sure if he did.
  • SC: It is assigned to PAC. If we have agreement, we would allow him to have last review and merge.
  • SC: We can drop the word "new". We might have an exception with WebID. If it's listed as a deliverable, it is not intended to conflict with out of scope.
  • SC: No objections.

ACTION: SC to integrate change from discussion on PR with eP. PAC to have last review and merge.

Consider adopting WebID 1.0 ED as a Deliverable

URL: solid/solid-wg-charter#39

  • SC: The proposal is to adopt WebID as a deliverable. We had several approvals from the CG perspective. At least one approval from WebID CG perspective. The specification is quite integral to Solid, been around for a long time, used by several communities outside Solid. It is mature. Things need to be improved, but it was deemed to be mature enough for Solid ecosystem to use widely. Lots of our specs and implementations use it. It is something we depend on. With respect to normative references, it would be in Solid WG's interest to run it through Recommendation Track.
  • SC: We need agreement that we want to take it on and no objections from WebID CG.
  • JZ: Presumably this would ease the work of the Solid WebID-Profile group because we'd have something that is already on track to be accepted in the WebID spec itself. Is that correct?
  • SC: Yes.
  • JZ: Then I'm in favor.
  • LD: This would mean we adopt the WebID spec within the WG? This would go beyond the WebID panel? Would also incorporate non-Solid-specific?
  • SC: Yes. It's non-Solid-specific. Solid WebID profile is one of the specs that uses it; other specs also use it (AuthN, etc.).
  • LD: Will we be able to maintain the boundary between the general WebID specification and the specific profile being defined for the Solid specification in the context of the Solid WG?
  • SC: WebID identity specification is strictly about identity. WebID profile is about data model.
  • eP: +1 to adopt
  • TBL: Crucial thing is that if this is something the server needs to understand, it needs to be at same level of maturity as Solid protocol. Things like what's in your WebID profile should not be there because not server's concern.
  • eP: Currently Solid OIDC depends on it because it specifies the issuer must be specified in the WebID document. WebID spec is lightweight. Only has two requirements.
  • SC: Objections to adding WebID spec as deliverable to the charter?
  • HS: No objections from me.
  • SC: HS, can you run it through WebID CG to see if there are objections to handing off the work to the Solid WG if the WG happens? The work could later be passed back to the WebID CG.
  • HS: Ok

Strategy for normative references

URL: solid/solid-wg-charter#37

  • SC: On W3C to give us go-ahead on what's necessary. Let's come back to it.

Update mission

URL: solid/solid-wg-charter#7

  • SC: This is editorial. PRs welcome.