Authorization focused meetings

[matthieubosquet]

On proposal

Solid authorization and Solid CG weekly meetings' times clash.

The authorization panel (like other panels) has suffered lately from low attendance.

We could focus on specific work items at a mutually convenient time on a bi-weekly basis with groups of interested people, starting with the Authorization UCRs.

Details

Current meetings

The Solid Community Group Calendar mentions only W3C Solid Community Group: Weekly Call.

According to GitHub/solid, the following meetings are happening:

• Authentication: Mondays, 14:00 UTC - room (14 recorded meetings in 2022, last in may)
• Data interoperability: Tuesdays, 14:00 UTC - room (8 recorded meetings in 2022, last in march)
• WebID Profile: (apparently) Tuesdays, 16:00 UTC - room (20 recorded meetings in 2022, last in October)
• Specification / CG call: Wednesdays, 14:00 UTC - room (15 recorded meetings in 2022, last in October)
• Authorization: Wednesdays, 14:00 UTC - room (9 recorded meetings in 2022, last in September)
• Notifications: Thursdays, 14:00 UTC - room (21 recorded meetings in 2022, last in September)
• Test Suite: Sporadically - room (3 recorded meetings in 2022, last in June)

Proposal

During the CG call on 2022-10-12, it was discussed that:

• Implementation work conflicts with weekly attendance to multiple panels;
• Panels/meetings should be more focused to allow for progress;
• We want to push forward specific work items towards completion;
• It seems important to give attention to authorization UCRs.

Maybe, considering the above, it would be good for those wanting to give attention to the authorization use cases and requirements to express interest in the dedicated issue and form a group that could meet once every two weeks at a mutually convenient time to progress the authorization UCRs towards an Editor's Draft status.

We could update the authorization panel meeting times to reflect this once we have a committed group for this specific work item.

Acceptance criteria

What actions are needed to resolve this issue? (checklist)

• Enough Solid-CG participants expressing interest in the authorization-ucr's editors issue
• Agreeing on a mutually convenient time for bi-weekly meetings focused on authorization UCRs

[elf-pavlik]

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.

[TallTed]

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.)

[csarven]

@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.

[woutermont]

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.

[matthieubosquet]

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).

[elf-pavlik]

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.

[bblfish]

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.

[woutermont]

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.

[matthieubosquet]

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?

[woutermont]

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.

[woutermont]

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.

[ThisIsMissEm]

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.

[elf-pavlik]

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)