Loops in revocable capability chains .

[John Carlson]

How does one look for loops in revocable capability chains?  Simply look for any reoccurrence of any token in the chain?  If I break the chain, how do I decide where to break it?

Also, what about revocable capabilities pointed at themselves?

Thanks.

[Alan Karp]

How would you get a loop?  Delegations form a tree.  Delegations of the same root capability to one party from different sources are separately revocable.  Say that Alice delegates to Bob, Bob delegates to Carol, and Carol delegates to Alice.  When Bob revokes Carol, that revokes the delegation Alice got from Carol but has no effect on the capability Alice has nor her delegation to Bob.

How do you get a capability that points at itself?  Every delegation is a new capability, if Alice delegates to herself, she now holds separately revocable capabilities.  This pattern is (should be) quite common.  For example, if Alice wants to read a file and has a read/write capability, she can enforce least privilege on herself by first delegating a read-only capability to herself. 

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAGC3UE%3DaentEAEv%2BYhVpg%2BtWERktjND-MP%2BP5w72UJD34mgLyg%40mail.gmail.com.

[John Carlson]

Great point.  I’m thinking of it either as a list or table of delegations.  If there’s no way to delegate to one’s own token, only delegate to new capabilities, that’s okay.  What I was thinking about was sending a message with  one token which forwards to another token …like invites to a collaboration session.  So revocations are safe, but making use of a capability might create a loop, back to the original, through your example. I understand that one doesn’t delegate to a preexisting capability.   So no loops are possible.

What I was probably thinking was a network or hierarchy of personal petnames, just a kind of goal for a user interface.  (I’m thinking of D3.js).

Thanks!

John 

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z2zZ7xy69DouQGiTd6YxjkK4u2eAgNEsOwnyYHRpkr2vw%40mail.gmail.com.

[Alan Karp]

You can still share capabilities, whether they be bearer tokens or certificates.  (In the latter case, you share the certificate and the corresponding private key.)  You can get loops in this case, but it's all the same capability, which is either revoked or not no matter who uses it.  Hence, there's still no problem.

--------------
Alan Karp

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAGC3UEnA%2BsbKT3ZxMY04LwtzNagMY%3DyHpW0yY0NThK8zNY3AGA%40mail.gmail.com.

[John Carlson]

I’m stumped on how to do send and receive tokens (not full access tokens), tying operations and resources together.  The best I seem to be able to do is provide a token per operation, then allow the user to employ/activate more than one at a time.   This typically means more than one socket and keeping ACLs of tokens (delegation chains) for each operation so one can revoke access.  My brain can’t think beyond that.

Probably OAuth2 offers a solution.

I’m not ready to create a database yet.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z0feTbCAxEr9s5_X3GJ3qrQOKXCZw__yaVQk00NF3-rTw%40mail.gmail.com.

[John Carlson]

I’m not opposed to a contacts app database on the client side, I just need to figure out encryption.

[Alan Karp]

OAuth 2 is a start, but it's limited in its handling of access tokens.  

There are two approaches to managing tokens that I've used, each with its own advantages and disadvantages.

One approach that we used in our Zebra Copy work is digital certificates.  That work used SAML 1.1 certificates; UCAN is more modern.  The basic idea is to treat the capability certificates as public documents that must be signed to be used.  Use is straightforward.  Any invocation of the designated object includes the request and the certificate, the combination signed by the private key corresponding to the public key the certificate was issued to.

Anyone with a capability certificate can delegate locally.  Say that Alice has a capability certificate she wants to delegate to Bob.  She asks Bob for a public key, which Bob generates for this purpose.  Alice creates a new certificate issued to that public key, perhaps attenuating the permissions, includes a copy of her certificate as proof of permission to delegate, and sends the new certificate to Bob.  

Each certificate has a unique identifier of some sort, which Alice can use to revoke Bob's certificate and any certificates derived from it.  In the Zebra copy approach, you could revoke any certificate you had created by sending a revoke message to the resource specified in the capability.  UCAN took a better approach -- revoke is a delegatable permission like any other.

Advantages include offline delegation and local verification.  Disadvantages include computational expense of validation and key management.

The second approach uses bearer tokens of unguessable values, such as OAuth 2 bearer tokens except they designate a particular resource.  You include this token when invoking the designated resource.  Delegation requires a token exchange.  For example, Alice sends a copy of her token to the resource designated by the token asking for a possibly attenuated new token, which she then passes to Bob.

There are several ways to verify that the token authorizes the request.  We used a hash table in one system designed by Marc Stiegler and me for a highly scalable HP internal service.  The token was the key; the value was the authorized permissions and the value of the token it was delegated from.  Delegation was by token exchange.  Validation involved following the chain of pointers until you reached the root capability, the one that didn't point to a parent.  Revocation replaced the pointer to its parent with a revoked designator.

Advantages include validation performance.  Disadvantages included requiring connectivity to delegate.

Other designs are possible depending on your particular requirements.

--------------
Alan Karp

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAGC3UEmbW425nhdO3brE8T7yB7BW%2B8LAcezpw2LpqSdBQTgWzQ%40mail.gmail.com.

[John Carlson]

I’ve used PEM and MOSS.  I used MOSS for exchanging invoices and acknowledgements with the Bank of America.  The disadvantage of this is you have to store a passphrase/password, or provide one for each set of transactions.

I worked with Jed Donnelley devising a system with GPG/PGP and Java for file system access.  As I recall, this used a password as well.

Thus, I am familiar with PKI.   The main issue is storing a passphrase, much like ssh-agent does.

I currently plan to upload session/gathering and  petname+token via Selenium Java test framework, then I will use tokens to communicate between the web browser and the socket.io backend over secure websockets.  One thing I am dealing with is CORS.

A unique id for revocation sounds cool.

I was thinking of Mark Stiegler approach, keeping a hashtable of token to permissions, which can be attenuated.  I think we already discussed following a chain of pointers to the root token.  A question would be following pointer in the opposite direction if send and receive are separate capabilities.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3b%2BdOCPHz7Fw%2B6DBN2TQKVEwwghgkfuN4G5NGFH8G%2B_A%40mail.gmail.com.

[Alan Karp]

Comments inline.

--------------
Alan Karp

On Thu, Oct 3, 2024 at 11:56 AM John Carlson <yott...@gmail.com> wrote:

I’ve used PEM and MOSS.  I used MOSS for exchanging invoices and acknowledgements with the Bank of America.  The disadvantage of this is you have to store a passphrase/password, or provide one for each set of transactions.

I had to look up PEM and MOSS.  PEM is authentication-based, and is clearly not suitable for a capability system.  I didn't see anything about a password in the description of MOSS, but it isn't suitable, either, if there's such a requirement.  Neither achieved widespread adoption according to ChatGPT. 

I worked with Jed Donnelley devising a system with GPG/PGP and Java for file system access.  As I recall, this used a password as well.

I'm dubious that something Jed designed used a password unless it was to bootstrap into a legacy file system.

Thus, I am familiar with PKI.   The main issue is storing a passphrase, much like ssh-agent does.

As far as I knowPKI doesn't need a passphrase, but standard key management tools do.  You should be able to manage private keys any way you choose.

I currently plan to upload session/gathering and  petname+token via Selenium Java test framework, then I will use tokens to communicate between the web browser and the socket.io backend over secure websockets.  One thing I am dealing with is CORS.

I must be way out of the mainstream; I had to look up Selenium, too.   Websockets appears to be a good way to communicate browser to browser, but I've never used them myself.

A unique id for revocation sounds cool.

A unique ID is part of every certificate system I've ever looked at, whether used for capabilities or not. 

I was thinking of Mark Stiegler approach, keeping a hashtable of token to permissions, which can be attenuated.  I think we already discussed following a chain of pointers to the root token.  A question would be following pointer in the opposite direction if send and receive are separate capabilities.

I don't see why you'd need the reverse lookup when send and receive are separate capabilities.  You might want such a table for audit purposes, but you can construct it from the primary table.   

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAGC3UEmprgxS8kg3AfyzLxObPRAwFu5YBtx-TvbJU4-r9RJTpA%40mail.gmail.com.

[John Carlson]

Replies inline.

On Thu, Oct 3, 2024 at 3:39 PM Alan Karp <alan...@gmail.com> wrote:

Comments inline.

--------------
Alan Karp

On Thu, Oct 3, 2024 at 11:56 AM John Carlson <yott...@gmail.com> wrote:

I’ve used PEM and MOSS.  I used MOSS for exchanging invoices and acknowledgements with the Bank of America.  The disadvantage of this is you have to store a passphrase/password, or provide one for each set of transactions.

I had to look up PEM and MOSS.  PEM is authentication-based, and is clearly not suitable for a capability system.  I didn't see anything about a password in the description of MOSS, but it isn't suitable, either, if there's such a requirement.  Neither achieved widespread adoption according to ChatGPT. 

I worked with Jed Donnelley devising a system with GPG/PGP and Java for file system access.  As I recall, this used a password as well.

I'm dubious that something Jed designed used a password unless it was to bootstrap into a legacy file system.

It was PGP/GPG that required a password to unlock the private key, I think.  His thought was to use public key encryption, as he described in his paper.  I implemented the system.

Thus, I am familiar with PKI.   The main issue is storing a passphrase, much like ssh-agent does.

As far as I knowPKI doesn't need a passphrase, but standard key management tools do.  You should be able to manage private keys any way you choose.

You can declare a default passphrase (empty), which is what I used in the Bank of America automated system.  It means your keys are available to people on the system.  There’s probably ways to do different key management these days.

I currently plan to upload session/gathering and  petname+token via Selenium Java test framework, then I will use tokens to communicate between the web browser and the socket.io backend over secure websockets.  One thing I am dealing with is CORS.

I must be way out of the mainstream; I had to look up Selenium, too.   Websockets appears to be a good way to communicate browser to browser, but I've never used them myself.

One communicates to and from socket.io on the server.  WebRTC is used peer to peer.  Selenium is over 10 years old, I’ve been out of the mainstream too.  MOSS and PEM are really ancient.

I’ve not tried WebTransport (HTTP/3) with socket.io.  The implementation looks like it goes outside of the standard socket.io packages.  A friend recommended Next.JS for multi-user stuff, but I assume he’s thinking a standard database implementation.  My database is mostly on the client and gets uploaded to the server, or hopefully, links sent via email.  My database is currently a 3 column affair, but I hope to add “primitive” types, like color.  Really, I need to move to spaces in property names and object ids too.  JSON or XML is attractive.  The contacts application might be pre-XML, I forget.

A unique id for revocation sounds cool.

A unique ID is part of every certificate system I've ever looked at, whether used for capabilities or not. 

I was thinking of Mark Stiegler approach, keeping a hashtable of token to permissions, which can be attenuated.  I think we already discussed following a chain of pointers to the root token.  A question would be following pointers in the opposite direction if send and receive are separate capabilities.

I don't see why you'd need the reverse lookup when send and receive are separate capabilities.  You might want such a table for audit purposes, but you can construct it from the primary table.   

True.  I wasn’t necessarily thinking of a single table.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3odBE5Fkg%3D1MX5foUVG9Dvqg625yPFbvCaKgrp6FTCSA%40mail.gmail.com.

[John Carlson]

The project is changing into a CSS project, like adding collaboration properties to CSS, possibly through a templating mechanism.

We’ll still keep the old code around.

[John Carlson]

On Thu, Oct 3, 2024 at 4:46 PM John Carlson <yott...@gmail.com> wrote:

Replies inline.

On Thu, Oct 3, 2024 at 3:39 PM Alan Karp <alan...@gmail.com> wrote:

Comments inline.

--------------
Alan Karp

On Thu, Oct 3, 2024 at 11:56 AM John Carlson <yott...@gmail.com> wrote:

I worked with Jed Donnelley devising a system with GPG/PGP and Java for file system access.  As I recall, this used a password as well.

I'm dubious that something Jed designed used a password unless it was to bootstrap into a legacy file system.

It was PGP/GPG system that required a password to unlock the private key.  His thought was to use public key encryption, as he described in his paper.  I implemented the system.

Check Section 8 to be sure:

http://www.webstart.com/jed/papers/Managing-Domains/

Sounds like a legacy file system.

We were implementing a file system on top of PGP/GPG.

John 

[Alan Karp]

The modern terminology for what Jed called a password is "bearer token."

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAGC3UEksDPp2brWOcHb2%3Da-xhXj2FTsmwRCY2un%3DbysdZjXrEw%40mail.gmail.com.

[Alan Karp]

(Hit Send too soon.)

The distinction between the common meaning of "password" and "bearer token" is that the former is associated with the user, and the latter is associated with the resource.

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAGC3UEksDPp2brWOcHb2%3Da-xhXj2FTsmwRCY2un%3DbysdZjXrEw%40mail.gmail.com.

[David Nicol]

Here's a high level summary of Websockets: Websockets is a layer atop TCP that marshalls the communication into "messages" which are arbitrary. There is facility in the specification for formatting the messages into records or objects and so on, but in my experimentation with them I found plain octet-string messages sufficient. Although there is much promise for browser-browser communication, setting that up is more complicated than server-browser communication, which I have had success at. Compared with either (a) setting up a TCP connection and parsing the data into discrete messages, or (b) hacky webgineering techniques like "comet", Websockets are a pleasure to work with.

On Thu, Oct 3, 2024 at 3:39 PM Alan Karp <alan...@gmail.com> wrote:

   Websockets appears to be a good way to communicate browser to browser, but I've never used them myself.

--

"At first it doesn't make any sense, which is perfectly all right" -- Ken Nordine

[John Carlson]

Not much of this is capabilities.   Most will probably be aware.

Typically, one uses WebRTC for browser-browser communication, which requires a server to set up p2p networking, except probably, browsers on the same network.

With connection upgrades one can go from http to ws or https to wss (secure web sockets).

Websockets are easier to set up than socket.io, but one can easily define APIs (in a [multi?] dispatch table sense, but that’s hidden) with socket.io, and broadcast or multicast from the server.   I’ve not had luck migrating Socket.io from node.js to deno (I have a dual purpose server), but there are demonstrations of socket.io only.

AFAIK, browsers communicate through a server.  I have not seen browsers accepting direct connections before, but I understand technology marches on.  Possibly the easiest is Server Side Events (SSE).  When the web moves to UDP, it may be easier to send to a browser (no connection needed), assuming the firewall is open.  I’m guessing DTLS will allow us to open a port in the firewall, or NAT will open a UDP port.

For a multi-user CRUD-like API with JavaScript in the browsers, one can choose Meteor.  I have not used this with authentication or authorization.  React is something one can use with Meteor.

This is a good overview of back-end technology: 

https://youtu.be/oVfw8Oj-uH8

John

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAFwScO8%3DMGwbzDrctkx8zF%2BxDR14DZ0OpkC04T4tbj1t%3D%2BP21g%40mail.gmail.com.

[James Diacono]

We implemented a peer-to-peer capability-based chat application using WebRTC as part of the uFork project. An overview and the code can be found at https://github.com/organix/uFork/tree/main/apps/peer_chat, if that is of any help. The server component runs on either Node.js or Deno.

[John Carlson]

I’m looking for something that can be used to host multiuser gatherings and perform shared teleoperation.  Capabilities or bearer tokens can be used to control different parameters of a 3D surface.  Perhaps there will be multiple 3D surfaces that can be parameterized.  Probably Zoom or Discord will be used for chat or teleconferencing.

I have a prototype based on bearer tokens. Eventually, I’ll probably get to revocation aka banning and attenuation.

I already have other plans for multiuser end-to-end security where only routing information is revealed.  I’ll try to find it and share.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/6102f6fb-3d17-428c-93e9-559d16d62e79n%40googlegroups.com.

[Valerio Bellizzomi]

Why don't you use Jitsi Meet for teleconferencing, it is an open-source alternative to Zoom and Discord.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAGC3UEmNRS79hszd80YisO1eyXKpTTDamFR4ENLn%3Dj-oWzRDLA%40mail.gmail.com.

[John Carlson]

On Wed, Jan 22, 2025 at 1:31 AM Valerio Bellizzomi <vbell...@gmail.com> wrote:

Why don't you use Jitsi Meet for teleconferencing, it is an open-source alternative to Zoom and Discord.

That doesn't sound popular, but I've heard of it.  Most of my community is around Zoom and Discord.  Slack was tried, and there's some new thing in Europe...Zulip Chat?  I already forgot the name and my password.  Getting people off phone/video teleconferencing into a 3D system, even though the whole meeting is about Web3D, is kind of weird.  Other systems have been devised for 3D that you've never heard of.  Secret?  Meta means death in Hebrew.  Are people on a Quest to meet in deathverse?

Really, I just want to build multi-user 3D collaboration thing that people can launch with weblinks or app links.  An iframe in Discord sounds super easy, except for Oauth.

Zoom sounds a lot cooler than Discord or Meta

The next place to be seems to be Blue Sky.  That's a pretty cool name.  Electric Light Orchestra - Mr. Blue Sky (Official Video)

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAKqWSW6L29%3DYYjKBUEOC9PM_GxXXRS6pxroff3_KPb3ps5xAyg%40mail.gmail.com.

[Valerio Bellizzomi]

On Wednesday, January 22, 2025 at 10:00:04 AM UTC+1 yott...@gmail.com wrote:

On Wed, Jan 22, 2025 at 1:31 AM Valerio Bellizzomi <vbell...@gmail.com> wrote:

Why don't you use Jitsi Meet for teleconferencing, it is an open-source alternative to Zoom and Discord.

That doesn't sound popular, but I've heard of it.  Most of my community is around Zoom and Discord.  Slack was tried, and there's some new thing in Europe...Zulip Chat?  I already forgot the name and my password.  Getting people off phone/video teleconferencing into a 3D system, even though the whole meeting is about Web3D, is kind of weird.  Other systems have been devised for 3D that you've never heard of.  Secret?  Meta means death in Hebrew.  Are people on a Quest to meet in deathverse?

Really, I just want to build multi-user 3D collaboration thing that people can launch with weblinks or app links.  An iframe in Discord sounds super easy, except for Oauth.

Zoom sounds a lot cooler than Discord or Meta

This is your personal opinion?

I just exclude any non-open-source solution.

 

The next place to be seems to be Blue Sky.  That's a pretty cool name.  Electric Light Orchestra - Mr. Blue Sky (Official Video)

Never heard of Blue Sky nor Zulip.

[Mike Stay]

Zulip is great for math discussions. It's free for educational
purposes. It supports LaTeX math mode inline. It has a concept of
named channels, under which there are named discussions. If a
discussion gets off topic, that set of messages can be broken out into
a new discussion. It's got nice moderation tools.

The category theory community has a huge server, with around 3400
members: https://categorytheory.zulipchat.com (If anyone wants an
invitation, please let me know privately.)

On Wed, Jan 22, 2025 at 9:16 AM Valerio Bellizzomi

> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/13f333ae-4d5c-4512-9e49-240cb7ea5dbfn%40googlegroups.com.



--
Mike Stay - meta...@gmail.com
https://math.ucr.edu/~mike
https://reperiendi.wordpress.com

[Alan Karp]

While we're on the (off) topic, the W3C community uses Jitsi for its meetings.

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAKQgqTbC5atvQmh-K%2B1yGSbw6mwk2Ba2b1ryo1pZiyKXjDRrQA%40mail.gmail.com.