Skip to content

Latest commit

 

History

History
141 lines (97 loc) · 8.61 KB

2022-08-25.md

File metadata and controls

141 lines (97 loc) · 8.61 KB
Raw

W3C Solid Community Group: Notifications Panel

Present

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

  • Pete Edwards

Introductions

  • name: text

Topics

WIP Implementation Feedback

  • SC: We'll allocate some time for implementation feedback going forward. Links to servers/applications welcome.
  • PE: Tests are related. Various difficulties on how to test. Put PR #86 together on specification-tests. But they might be addressed by the plans you got in this meeting.
  • SC: Let's see then..

Solid Notifications Protocol: Review notes

URL: solid/notifications#76

ACTION: SC and AC will process and respond to this issue (some items may already have been addressed)

  • SC: I responded to Tim's review in solid/notifications#76 (comment) . I did not respond to comment on performance as what is being proposed will take the spec in a different direction. Does Aaron want to tackle that?
  • AC: I will address this and confront the concerns.
  • SC: It does not need to block the next publication but we need a response we can lean on
  • RG: We had an extensive chat and Aaron explained. Some of what's in Aaron's head should be on paper.
  • AC: Agreed.

ACTION: AC to respond to design re performance of making the connection for live updates.

Remove server-subscription-access-read

URL: solid/notifications#99

  • SC: There are some use cases ... if spec is to provide all sorts of notifications, not all notifications will require read. It gets more complicated when dealing with resource creation. How can you subscribe to something that doesn't exist yet? You don't have read on it. Or try to access a document, get 403 — can you send a notification request to notify when you do get access? Easier to separate access controls on the resource from the resource server and the subscription server. Have a way of advertising policies on these subscription, e.g., you need 'read' on a resource to subscribe or payment required.

  • SC: Any objections to merge?

  • AC: +1

  • PE: +1

  • RG: +0.9

  • RG: Can we clarify notification and subscription endpoint? Seems used interchangeably.

  • SC: Yea, the issues/pulls coming in this agenda address that.

Clarify authentication-authorization section

URL: solid/notifications#102

  • SC: Any objections to merge?

  • SC: Notification protocol does not need to set a constraint on forms of authentication access.

  • AC: A lot of ways we can think of access control. Resource-centric on solid resource or subscription endpoint/api. Solid is maturing, and there are other notions of authz, like VC. So we can be more precise — this generalisation opens that up for other kinds of mechanisms.

  • PE: I don't feel I can comment — haven't been following.

  • RG: Same. I can barely follow your argument.

  • PE: I understand the principle of keeping the detail out. That makes sense.

  • SC: Part of the comment is non-normative, pointing to another spec, but the normative part says you really need to use access controls. Current approaches are in direction of WAC and ACP, but you could have something else providing authentication. The notification protocol encourages use of specs without saying which. Other protocols could be OK.

  • RG: Isn't the authn being handled by the subscription endpoint?

  • AC: Yes. In terms of what mechanism is use (UMA, GNAP, Bearer), we are not saying which to use. It needs to be authenticated with a suitable mechanism.

  • RG: I thought by having a subscription endpoint, it will happen on the server side, hidden away from the client

  • SC: What do you mean by completely on the server side? When you check the endpoint, it will advertise how to authenticate

  • RG: Would the client have to ask for authn separately, or wouldn't asking for the subscription cause it to be handled?

  • SC: You post to the endpoint; it will respond with a description and endpoint URL telling you how to proceed

  • RG: Isn't the endpoint given after authentication?

  • SC: First you make the request, after discovering the notification channel. "I want WS subscription with these features", it responds with source to make the connection. When you post, you have already authenticated

  • RG: During that POST, you are providing authn token or are pre-authenticated to get the subscription endpoint

  • AC: The endpoint is there either way; you don't need to authenticate to find it. But when you interact to create a subscription, that process involves authz header. It is enforced and you proceed from there

  • SC: The client can discover that before making the POST. The proposal here is that we don't say what the requirements are; we let other specs alongside answer the question.

  • RG: OK

  • SC: Any objections to merge? Or vote.

  • AC: +1

  • RG: +0.0

  • PE: +0.5

Add subscription-request-statements and server processing

URL: solid/notifications#100

ACTION: SC to merge this PR and will make a follow-on PR to address the required triples for non-JSON-LD serializations

  • SC: Any objections to merge? Mostly editorial work.

Update notification channel discovery and conformance

URL: solid/notifications#104

  • SC: I can clarify here. Would like to merge as soon as possible if no objections — there is rough consensus in the issues that's referenced.

  • SC: We had outstanding issue on finding statements about the notification channel. We're talking in terms of subscription, but that is one type of notification. (SC outlined the changes in the PR). This clarifies how discovery will work and conformance rules for the description of the channel, formalising what's in the spec. One topic not included was interchangeability of terms. Resource has a notification service(s) which will describe something like a websocket as a subclass of a service. Notification channel resource is an RDF source (separate requirement).

  • SC: Please vote.

  • AC: +1

  • PE: +1

Interchangeable use of notification channel type and subscription type

URL: solid/notifications#71

ACTION: Find consensus on the solution to this, produce a proposal, and make a PR by next meeting (2022-08-25)

  • SC: Can we do that after merging solid/notifications#104 ?

  • AC: I don't want to drag us back into an earlier issue. If we are talking about terms of services, we might want to consider that IANA has a link relation called service or service_doc. If we are changing the terminology to service, that could be a useful way of being consistent and avoiding challenges with working with the POWDER working draft.

  • SC: This PR didn't propose 'service' but the point is clear. Can Aaron follow up on this in issue #71?

  • SC: host-meta was mentioned in solid/specification#355 (comment) but ruled out. Can't remember now if that's the same/related.

  • RG: I remember Ted saying something 3 months back.

  • SC: Please provide references in issue.