Comments (13)
Let's settle this then? We take one slot, weekly on Monday, and in a month or so we can evaluate whether a second slot is needed?
Do we have a preference to start with the 14:00-15:00 slot (currently used by AuthN) or the 15:00-16:00 slot (currently used by Interop), both on Mondays? Let's indicate preferences with
Edit: tagging panel members present in last few meetings or often present the past year; @elf-pavlik @justinwb @angelaraya @laurensdeb @ericprud @acoburn @ThisIsMissEm @csarven @matthieubosquet @NSeydoux @barath ... please tag who I might have missed.
from authorization-panel.
Thank you @matthieubosquet!
I know that Data Interoperability tries to find a different time due to conflicts emerging for key participants. If Tuesdays work for everyone interested this could be an option. It still does work for me.
In general, most groups should be able to alternate their meetings, as we see most of the groups don't seem to need more than 26 meetings per year. With bi-weekly schedules, we can pack more meetings in fewer timeslots.
from authorization-panel.
In the next month I should have a new proposal for HttpSig in authentication. That should slowly have ripple effects on Authorization.
I am still finishing an implementation of the latest spec in bblfish/httpSig#12 (which has taken a couple of weeks longer than hoped). When that is done I need to re-implement client and servers which will allow me to update our use of that ietf spec. I mention this as a topic that will certainly soon pop up.
from authorization-panel.
The last 2 reported meetings for authentication were on November 7th and May 23rd.
The last 3 reported meetings for data interoperability were on December 5th, November 21st and August 3rd.
Given:
- how sparse meetings actually are
- limited availability of participants
- the interlinked nature of interests
I would propose considering a weekly at 1400 UTC with a flexible agenda in terms of focus (authn/authz/interop).
We can organise a queue shifting from one to the next and skipping when nothing is to be discussed for the next focus.
I think there is a lot of value in having a clear timeslot for all and if we find that weekly (or every 2/3 weeks per subject) is not enough, we can allocate new timeslots. But for now, I think a dedicated timeslot would be best (also ensuring participants' availability).
What do you think?
from authorization-panel.
The Solid Community Group Calendar mentions only W3C Solid Community Group: Weekly Call.
It would be very helpful if all panels, task forces, etc., could be added to that calendar, so they automatically appear on subscribers' calendars (including my own) making it more likely we attend as well as making conflicts more easily visible.
(Along these lines, I wonder whether this issue would be better on a more general repo, than on authorization-panel
in particular.)
from authorization-panel.
@TallTed , I want to acknowledge again that we/I can add the events to the W3C calendar - there is no blocker. I just want to make sure that there is some rough commitment before notifications are sent around. The CG has >250 members at the moment and even if some turned off notifications, I'd prefer to keep notifications to those subscribed to minimal.
GH issues/PRs works reasonable okay to get things rolling.. but if people want to use doodles to get some initial number of people committing, that's all welcome.
from authorization-panel.
Since @csarven asked to post it here, I'll repeat our confirmation from #309 (comment): we would definitely like to [continue to] contribute our findings about use cases we encounter(ed) in the field.
from authorization-panel.
We have discussed the Solid CG calendar during the Solid CG weekly call on Wednesday 7th December.
We could align authorization-panel meetings to authentication-panel and data-interoperability-panel meetings that already happen monthly on Monday.
The monthly schedule seems sensible and having a known day and time for all meetings might be the most convenient for everyone.
How does it sound to you @woutermont, @elf-pavlik, @csarven?
If we're all happy with this, I'll follow up with PR(s) (to update the readme(s)) and would be happy to work with Sarven on updating the CG calendar (as per @TallTed's suggestion).
from authorization-panel.
Interop meetings are currently scheduled as bi-weekly. AuthN are irregular with estimated average once a month, picking one of the slots not used by Interop.
While currently Interop and AuthN use different UTC time 15:00 and 14:00. I think we should be cautious with considering them as two different slots since DST changes might result in need to some adjustments, which shouldn't lead to a need of resolving collisions.
from authorization-panel.
If Interop is meeting bi-weekly, both AuthN and AuthZ could meet four-weekly (~monthly), if that is enough. I believe that, depending on the context, this will be too sparse though.
We could have all three use the slot on an as-needed basis, but that might be too complex to organise.
We could also use both hours as separate slots: one for AuthZ and AuthN alternating bi-weekly, one for Interop bi-weekly, with the other weeks available for any additional meetings. Since we're then three panels sharing two hours, it should not be that hard to reschedule something if DST results in bad timings for some people.
from authorization-panel.
I agree that meetings have been sparse, but I do feel that in at least two of the panels there has been an increased activity this fall. So I'm not sure 1h/w is enough to host 3 panels once they gain momentum again (like they are doing now).
If participant availablity is really an issue, I would agree that a single time slot would be better. Though unless there is a real indication thereof, I'd feel more comfortable using 2x1h slots. Then again, as you said: we can always start with 1h and (re)open an extra slot of necessary.
from authorization-panel.
Just a heads up, Tuesday's tend to be terrible for myself and @NSeydoux, as they tend to be the day our internal team meetings all take place, as I don't work on Monday's. Wednesday's or Thursday's tend to be more regularly open in our calendars, iirc.
We're also not currently actively working heavily on Authn/Authz stuff on the Inrupt Developer Tools / SDK team, as we're focused on some other more high priority work in our other SDKs, so if you do want our input specifically on something, feel free to tag us in a comment & we'll take a look.
from authorization-panel.
What do you all think about discussing next steps upcoming Wednesday during the CG call? Last time CG call lasted 5 min since there were no topics.
IMO we shot ourselves in the foot when we decided to work separately on AuthZ and AuthN. Some details in gitter chat.
TL;DR end-user authentication can rely on their authorization for the client. Also in some cases the client should be able to authenticate independently of the user. Currently most AuthZ depends on AuthN and AuthN is mostly used in AuthZ. Trying working on AuthN and AuthZ separately feels pretty counter productive to me and I'm afraid will lead to less secure designs.
It looks like we will get some good experience from Notifications Panel. Where Notifications Sender is pretty much always a server side application which sometimes has to work as a client needing AuthN/AuthZ. Also big part of Notifications Receiver implementations will be server side and they also will need to act as a client needing AuthN/AuthZ. Same with Subscription Client running server side in many cases.
EDIT Some relevant comments from @jaxoncreed solid/notifications#146 (comment)
from authorization-panel.
Related Issues (20)
- Required Credentials Discovery HOT 6
- support Trig serialization of Access Control Resources
- define a 2nd relation for ACRs to go with "acl" HOT 1
- Ideas for access modes and corresponding operations in the Protocol HOT 53
- acp:CreatorAgent logic HOT 5
- place meeting minutes on "draft-minutes" branch HOT 3
- Process Point of Order in meeting 2021-09-29 HOT 15
- ACP Draft design flaw HOT 18
- Distinction between policies which can be enforced by technology and by law HOT 5
- Enforce a secure default for client restrictions HOT 5
- Consider ACP matcher for conditional by relationship
- Update authorization-ucr's editors HOT 5
- Specify that the modes available are calculated using the resolution algorithm.
- Remove acp:mode from Context properties HOT 2
- Cannot match a context that contains a client/issuer HOT 4
- ACP vocabulary base URI problems HOT 1
- Serve ACP vocabulary from its base URI
- Clarify and/or mitigate risks related to negation (acp:deny) HOT 2
- ACP acronym also used for: Authoritative Claims Provider (OIDC + VC)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from authorization-panel.