Authorization focused meetings about authorization-panel HOT 13 OPEN

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 🎉 for the earlier one, or 🚀 for the later one.

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:

1. how sparse meetings actually are
2. limited availability of participants
3. 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.