Skip to content

Latest commit

 

History

History
106 lines (90 loc) · 11.1 KB

2022-04-20.md

File metadata and controls

106 lines (90 loc) · 11.1 KB

W3C Solid Community Group: Solid Editors

Present

  • Sarven Capadisli
  • Kjetil Kjernsmo
  • Justin Bingham
  • Ruben Verborgh
  • Tim Berners-Lee

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

Scribes

  • Sarven Capadisli

Introductions

  • name: text

Topics

Nature of Milestoning

  • KK: We need to understand the nature of contributions we get from the community. And see if community is interested and then based on that we decide to prioritise. First we should have a nomination of things that should go in there and then it goes through us.
  • JB: Do you feel that's not what we are doing? We should indeed adjust based on the feedback we get. We need to give a baseline.
  • TBL: We need to move. If we spend too much time on roundtrips with the community - we don't have time to do that. It is a hugely funded project with a community.. The spec is missing things that it needs to have...
  • KK: The problem is that we are only two people and now we are just one. The commitment of resources is important.
  • TBL: Asking people how important things are ??? We can say these are priorities and we need help with these. If you feel you want to work on that that's fine too - open source and what not. We need to prioritise.
  • KK: Let's not make the impression that we sat the priorities down. It is a proposal. We need to have an idea of priorities from outside of the group. We might have done it the wrong way but we have done it.
  • JB: Contributions can come in different forms. Lot less people stepping up to write spec test. The items we looked at, there are implementations out there from different parties. Maybe contributions in code vs documentation, this is what we want to do and this is what we want in the spec. Okay we are all focused on this work and see if they can support. I think a big part of the reason that we haven't is because it is scattered with issues. I don't know for sure but I feel we can get more energy/support if we lay this out and channel it.
  • TBL: That's why I made the top-level roadmap. Normal people can see the priories.
  • SC: My understanding was that we are proposing and get feedback.
  • JB: Same.

Solid OIDC and Solid OIDC Primer

  • SC: PR #386
  • SC: We have three reviews. Nothing major blocking besides basic changes in order publish (license, version information and identifiers) - they can resolve that soon. I asked to get a diff on ED and the proposed ~FPWD/CG-DRAFT so we can better understand/evaluate...
  • JB: Seems reasonable. I've approved because it is draft and have implementation experience on the client and server side. Aaron's point 1 is correct. It is not difficult for implementations to support this. The underlying library will tgive make it possible to deal with the tokens. re webid scope, makes sense. I don't think that's an issue for implementers - because I've done it. The JSON-LD context documents, it is not a big lift for implementers either. Meeting in the middle of the road re dealing with JSON principally. Bridging two. I've worked with client identifier document and also mixed with in ??? other context. Find it workable. These changes/deltas in mind, they shouldn't be blocking especially it is a draft. My feedback that's also nonblocking. There is intro that mentions UMA for authorization server. That is a SHOULD. You can be conformant without it. I've create a separate issue on Solid OIDC repo that basically said: there should be more supplementary context added. In case implementer wants to support - UMA in particular. In Primer there should be another flow that really demonstrates robust use of that. The Primer is updated to match the spec but it doesn't really explain why to support it. Show why useful/valuable.
  • TBL: I wish people that put a MAY in a spec send me a thousand dollars (USD)? Are we going to put into SolidOS this functionality or not. Basically you have lack of interop if you don't' have everyone implementing the same protocol. To have particular constraints on it. But either every pod does this or does not. If you have extra functionality like server based queries then we make it so that clients assume that if you want the server to support the clien twill write the code. But every time these optional things we lower the interoperability of the Solid space. So what does this UMA - how many other MAYs/optionals= are there?
  • KK: There aren't a lot of MAYs in the spec.
  • JB: Specifically it is a SHOULD.
  • TBL: SHOULD is worse. "This is really useful, you should really do it". but if someone doesn't do it then it damages. What is the value of UMA? summarise?
  • JB: First you don't require it and what you get to work with is going to be in terms of the data structure you get it to work with as a client is going to be the same - I believe. The diff is AS implements ??? you have the ability to provide richer control over the access that's given. If you are familiar with OAuth scopes - which is really broad and problematic. With UMA it is more specific.
  • JB: You're not wrong. The issue we have - there needs to be more context, what would be the flow. The spec doesn't need more normative. Everything works now essentially without it. To factor in without UMA. UMA was designed on top of OAuth to finally manage access specific elements besides broad scopes.
  • TBL: How are the data elements identified in UMA?
  • JB: It is open to interpretation.
  • TBL: The sounds as though it is a competing design to WAC and ACP.
  • JB: No, I would say it should - I'm not an UMA expert - provide a channel through which you can use WAC or ACP to implement access level decisions. UMA doesn't specify a model for that.
  • TBL: Does not make sense to me.
  • JB: We need more context on this piece.
  • KK: wouldn't UMA influence the interactions?
  • JB: ???
  • KK: ???
  • KK: My main concern is there are something like 10 different HTTP request before the RS can respond - which is very heavy. Even though I expect it to have some optimisations there but I don't see it. At least in the Primer.
  • JB: We already agreed to link to Solid OIDC ED. I believe that your criticism is.. there is a lot of back and forth. That's essentially how OAuth and OIDC operate. We said we use this. We are built on this.. i wasn't expecting this submission to change those fundamentals. This would be a consideration on why we want a different protocol with less back and forth.
  • KK: We are already invested in OIDC already. But it might be that it challenges.. how can we use caching for example to see if we can reduce the number of back and forth. If we are doing 10 requests for every access then this is not going to work - be too slow. Something has to be done there.
  • JB: Which access are you referring to?
  • KK: The resource that's on RS and uses primary.. and expect that you won't do 10 requests before getting the data. But the spec doesn't say anything about that.
  • JB: The spec tells you how to get the credential. But once you have the token you are including that in your request so you don't have the ceremony every time.
  • KK: It doesn't really say that / how long that token is valid.
  • JB: Configurable. There is expiry/refresh.
  • KK: That's what I'd expect but couldn't make that out from the spec or the primer.
  • KK: That is something I can live with WIP.
  • JB: The references included in the spec back to OAuth2 and OpenID.. that is covered in the underlying specs. YOu can provide those considerations.
  • KK: Up to now it has been clear what is an authn and what is authz. Since OAuth is using what access also for who.. it is confusing.
  • TBL: It is a violation of the architecture. Generally recognised that authn and authz layers separate. It is important because we need to be able to swap out Solid OIDC. No scopes.. no lists of resources it can acesss.. no other metadata. It is generally considered to be a good design of separation in Solid. For example, with WebID-TLS to WebID/Solid-OIDC so that people can do different things i the future.
  • KK: I don't know if that separation is violated but there is different use of terms that might indicate but confusing..
  • JB: The reason why ... an OAuth token is meant to represent a delegated authz for some app to access on my behalf. So the token they hold .. I've been authorized by Justin.. but the term is also used elsewhere.. and can get confusing. At minimum we would benefit an explanation. We obviously have more going on.
  • SC: Context of those terms are the specs. As confusing as it may be globally.
  • SC: I'd like us to focus on resolving the spec version.
  • TBL: For whatever number is what they want to represent their journey.. if we insist that we do it one way, then that's an impossibility / over-constraining. We point to our specs but not require them to conform to some scheme
  • SC: {discussion on versioning}
  • TBL: {discussion on versioning}
  • SC: Can Solid OIDC be Version 0.1.0? And Primer can be Version 1.0.0?
  • KK: 0.1.0-ed.1?
  • JB: +1 to semver - no opinion on specific version
  • TBL: -1 to semver based on experience that.. I'm assuming they will be like code and will have requirements of dependencies.. semver works well for above 1.0 and you can change the version and it means it is incompatible. If you change the minor number you have back compatibility and new one has more functionality.. and change the patch level... that seems to work without major numbers. If first is 0. then next level down implies then it is a mjor incompatible spec.. you can't use the piece. And then people end up using 0.234-alpha-6_3 (???).
  • TBL: Start at 1.0.0
  • JB: What I typically do I use this 0. while working. when functionality complete i start at 1.
  • TBL: For Solid Protocol we had it working long time ago. So it should be like 5.6.3.
  • KK: Semver works best after 1.
  • TBL: Why not 2.0...
  • JB: People put too much stock on them.. lets give them versions .. and Tim is right.
  • TBL: Solid OIDC 5.0.. because they had five breakages.. to change the whole ecosystem.. on the client and server. Roughly five.
  • SC: well, that's a good point but as;dfkjads;lfaj;flakdja;lkfjdafa;ldsf
  • SC: I'll follow up on getting the requested changes in place and merge. They may create a new PR.