Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Make AuthN/AuthZ of each channel explicit #155

Open
elf-pavlik opened this issue Feb 12, 2023 · 4 comments · May be fixed by #182
Open

Make AuthN/AuthZ of each channel explicit #155

elf-pavlik opened this issue Feb 12, 2023 · 4 comments · May be fixed by #182
Assignees
@elf-pavlik
Milestone
0.3

Comments

@elf-pavlik
Copy link
Member

Currently each channel doesn't specify AuthN/AuthZ method which it relies on. Instead we have implicit relying on what Channel type defines. I think each channel should specify what AuthN/AuthZ the receiver or the sender should use when receiving or sending notifications.

I'm going to track this issue inline in:

Related issues:
@elf-pavlik elf-pavlik mentioned this issue Feb 12, 2023
Merged
@elf-pavlik
Copy link
Member Author

elf-pavlik commented Feb 14, 2023 •
edited
Loading

I think the first step would be to make it explicit when Capability URL is being used for the receiveFrom and sendTo. I think we could simply define an individual solid:CapabilityURL and predicate notify:authScheme which would be used as part of Notification Channel description.

{
  "@context": [
    "https://www.w3.org/ns/solid/notification/v1"
  ],
  "id": "https://channel.example/ac748712",
  "type": "WebhookChannel2023",
  "authScheme": "CapabilityURL",
  "topic": "https://example.org/guinan/profile",
  "sendTo": "https://webhook.example/d4cf3f19",
  "startAt": "2023-01-01T07:00:00.000Z",
  "endAt": "2023-01-01T09:00:00.000Z",
  "rate": "PT5M",
  "state": "e75-TFJH"
}

In case of the StreamingHTTP channel we could add alias to JSON-LD context
"SolidOIDC": { "@id": "https://solidproject.org/TR/oidc" } and have

{
  "@context": [
    "https://www.w3.org/ns/solid/notification/v1"
  ],
  "id": "https://channel.example/guinan/profile",
  "type": "StreamingHTTPChannel2023",
  "authScheme": "SolidOIDC",
  "topic": "https://example.org/guinan/profile",
  "receiveFrom": "https://example.org/guinan/profile.notifications",
  "startAt": "2023-01-01T07:00:00.000Z",
  "endAt": "2023-01-01T09:00:00.000Z",
  "rate": "PT5M",
  "state": "e75-TFJH"
}

@elf-pavlik elf-pavlik added this to the 0.3 milestone Feb 14, 2023
@jaxoncreed
Copy link
Contributor

Are there any use cases where the authScheme for a specific notification protocol wouldn't be the same in all occurrences? I mean future-proofing is fine, but at some point the continual atomization of concepts just adds complexity.

@elf-pavlik elf-pavlik mentioned this issue Feb 28, 2023
Open
@elf-pavlik elf-pavlik mentioned this issue Mar 23, 2023
Open
@elf-pavlik elf-pavlik mentioned this issue Mar 31, 2023
Closed
@elf-pavlik elf-pavlik self-assigned this Apr 6, 2023
@elf-pavlik elf-pavlik mentioned this issue Apr 19, 2023
Open
@elf-pavlik
Copy link
Member Author

Since we want to describe the auth scheme for a specific URL, given that besides receiveFrom and sendTo we will also have URLs to unsubscribe and/or update subscriptions, it might make more sense to use that specific URL as the subject in the statements, so the examples above could change to:

{
  "@context": [
    "https://www.w3.org/ns/solid/notification/v1"
  ],
  "id": "https://channel.example/ac748712",
  "type": "WebhookChannel2023",
  "topic": "https://example.org/guinan/profile",
  "sendTo": {
    "id": "https:/webhook.example/d4cf3f19",
    "authScheme": "CapabilityURL"
  },
  "startAt": "2023-01-01T07:00:00.000Z",
  "endAt": "2023-01-01T09:00:00.000Z",
  "rate": "PT5M",
  "state": "e75-TFJH"
}
{
  "@context": [
    "https://www.w3.org/ns/solid/notification/v1"
  ],
  "id": "https://channel.example/guinan/profile",
  "type": "StreamingHTTPChannel2023",
  "authScheme": "SolidOIDC",
  "topic": "https://example.org/guinan/profile",
  "receiveFrom": {
    "id": "https://example.org/guinan/profile.notifications",
    "authScheme": "SolidOIDC"
  },
  "startAt": "2023-01-01T07:00:00.000Z",
  "endAt": "2023-01-01T09:00:00.000Z",
  "rate": "PT5M",
  "state": "e75-TFJH"
}

@elf-pavlik elf-pavlik mentioned this issue May 11, 2023
Open
@elf-pavlik
Copy link
Member Author

elf-pavlik commented Jun 29, 2023 •
edited
Loading

As mentioned during the call, the matrix of current channel types and auth schemes:

receiveFrom

type implied other in demand
WebSocketChannel2023 Capability URL some token based approach
StreamingHTTPChannel2023 Solid-OIDC Capability URL
EventSourceChannel2023 Capability URL

sendTo

type implied other in demand
WebhookChannel2023 Solid-OIDC Capability URL, solid/specification#504
LDNChannel2023 Solid-OIDC #148 , solid/specification#504

I think we need to support more than one channel type. Also keeping in mind that the ecosystem needs to be evolving. This year Capability URL might be the most accessible. Next year we may get something out of solid/specification#504. I don't think there is a need to update channel types as the ecosystem evolves. Something like the suggested authScheme makes it extensible.

I also would like to acknowledge that we will need a section in Solid Protocol (or a separate document) that requires a specific common subset of channel types and auth schemes to be supported for given version of Solid Protocol.

elf-pavlik added a commit to elf-pavlik/notifications that referenced this issue Jul 6, 2023
@elf-pavlik
explicit channel auth scheme
6012fc8 
closes solid#155
@elf-pavlik elf-pavlik linked a pull request Jul 6, 2023 that will close this issue
Open
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@elf-pavlik elf-pavlik

Labels
None yet
Projects
None yet
Milestone
0.3
Development

Successfully merging a pull request may close this issue.

explicit channel auth scheme elf-pavlik/notifications
2 participants
@elf-pavlik @jaxoncreed