A term for universal access

[Alan Karp]

Say your blog is controlled by capabilities, but you want anyone to be able to read it.  Is there a term to describe this situation?

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

[Tony Arcieri]

"World readable" comes to mind for me

--
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/CANpA1Z2VBh4dGHi-wFQivdx_OhGoFuNGvXWe1hMk3K-A0HvF6g%40mail.gmail.com.

--

Tony Arcieri

[Mark S. Miller]

We use Norm Hardy's term "widely held".

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

[Raoul Duke]

hm, even if there is no cap at all? i am assuming that was how it would work for the op. 

You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAK-_AD7gW4J7QRoiGZAx5DodtDAJJ_HHVppP4Y%3DL8wJe%2BNOtiw%40mail.gmail.com.

[Alan Karp]

On Wed, Sep 7, 2022 at 11:07 AM Tony Arcieri <bas...@gmail.com> wrote:

"World readable" comes to mind for me

I'm looking for a more general term.  Say I have a wiki that anyone can use.

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

[Tristan Slominski]

Public?

--

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/CANpA1Z36dh3XWZ5WCRoXbWzDTa4e0VcU2MgmDa2YysZQXKxoGQ%40mail.gmail.com.

[Mark S. Miller]

No. We use "widely held" only for caps.

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

--

  Cheers,
  --MarkM

[Benjamin Goering]

One of my favorite underrated parts of the activitypub spec is assigning a URI for ‘public’ things.

https://www.w3.org/TR/activitypub/#public-addressing

5.6 Public Addressing

In addition to [ActivityStreams] collections and objects, Activities may additionally be addressed to the special "public" collection, with the identifier https://www.w3.org/ns/activitystreams#Public. For example:

EXAMPLE 10

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://www.w3.org/ns/activitystreams#Public",
  "type": "Collection"
}

Activities addressed to this special URI shall be accessible to all users, without authentication. Implementations MUST NOT deliver to the "public" special collection; it is not capable of receiving actual activities. However, actors MAY have a sharedInbox endpoint which is available for efficient shared delivery of public posts (as well as posts to followers-only); see 7.1.3 Shared Inbox Delivery.

Sent from my iPad

On Sep 7, 2022, at 14:45, Mark S. Miller <eri...@gmail.com> wrote:



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

[Rob Meijer]

Think there are multiple scenarios that probably need a different term each.

1) No capabilities between frontend and backend. The backend is basically a public proxy for the read-only caps.

2) The frontend receives read-only caps without any audit properties added to it, think this is the widely held variant

3) The frontend receives capabilities that are audit wrapper for the actual read-only caps. Nu clue about a term for this one.

I feel it is especially difficult to communicate about these and keep people from trying to do access control,

other than cap-governed revocation, with audit data. There are (at least) three variants of #3. 

* Audit wrapper caps without identity and without identity derived attributes (for example just time, IP, agent, isued_by)

* Audit wrapper caps with identity

* Audit wrapper without identity but with identity derived attributes ( for example organisational_unit or month_of_birth )

There is another terminology issue here regarding revocation. If you hold a revocation cap for the audit wrapper cap, there can

be a combination of audit info fields that effectively designate the audit wrapper cap, but that is a problem in the lingo because

designation is supposed to be authorization, but in this case it isn't. You have designating audit fields for the audit wrapper and you

can use that only to look up if you have a matching revocation cap for the audit wrapper. 

 

--

[Charlie Landau]

On 9/8/22 3:09 AM, Rob Meijer wrote:

There is another terminology issue here regarding revocation. If you hold a revocation cap for the audit wrapper cap, there can

be a combination of audit info fields that effectively designate the audit wrapper cap, but that is a problem in the lingo because

designation is supposed to be authorization, but in this case it isn't. You have designating audit fields for the audit wrapper and you

can use that only to look up if you have a matching revocation cap for the audit wrapper. 

When you hold a revocation cap, *you* don't hold the audit wrapper cap. Conceptually, you hold a cap to an object that holds the audit wrapper cap, and allows you to revoke but not invoke.

--
Charlie Landau
he/him/his (Why Pronouns Matter)

[Rob Meijer]

The terminology issue comes when something designating (not a cap) is written to an audit log, we determine it was some form of service abuse, 

and I want to revoke the audit wrapper where that log line originated from. I'll parse the log, extract the designation, look up the revocation cap maybe

in some dictionary using that designation and I'll revoke the right audit wrapper cap from my collection of audit wrapper cap revocation caps.

There is a designating thingy that isn't a cap that allows you to find the proper revocation cap.

[David Nicol]

I am understanding the question as how to describe an ALLOW ALL access control semantic using capability terminology, if not how to implement one using capability mechanisms.

The for-everyone capability is going to wind up Widely Held, but there shouldn't be anything special about the capability in contrast to a capability that isn't going to be shared so easily.

"Public" capability seems natural to say. The capability becomes public by intention of the party sharing it.

My uncredentialed two cents approves "public" as the desired term.

[Alan Karp]

That works for capability URLs, but how would it work for certificates?  I guess you could use something like "public" in place of the public key.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/7D377E20-49CB-47A9-833E-E08FB06037CA%40bengo.co.

[Mark S. Miller]

For ocaps, or properly mixed ocaps and cryptocaps, you cannot actually allow all. But you can allow all who are not confined. If you could allow all, confinement would be impossible.

For cryptocaps alone, you can allow all, which does indeed make confinement impossible.

--

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/CAFwScO_E5T9p9h1kF-x2Yc2ov_Ler1Ae5zYOOpgMBUF8%3D2q1sQ%40mail.gmail.com.

[Charlie Landau]

On 9/7/22 9:46 AM, Alan Karp wrote:

Say your blog is controlled by capabilities, but you want anyone to be able to read it.  Is there a term to describe this situation?

You may want anyone to be able to read it, but I may want to put a program in a sandbox and deny access to it. Who gets to win?

What does "anyone" mean? It seems like that term invites something like the Russell paradox.

--
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/CANpA1Z2VBh4dGHi-wFQivdx_OhGoFuNGvXWe1hMk3K-A0HvF6g%40mail.gmail.com.

[Mark S. Miller]

On Fri, Sep 9, 2022 at 4:16 PM Charlie Landau <cha...@charlielandau.com> wrote:

On 9/7/22 9:46 AM, Alan Karp wrote:

Say your blog is controlled by capabilities, but you want anyone to be able to read it.  Is there a term to describe this situation?

You may want anyone to be able to read it, but I may want to put a program in a sandbox and deny access to it. Who gets to win?

In a system with ocaps (whether it also has cryptocaps or not), the confiner wins. In a system with only cryptocaps, the publisher wins.

 

What does "anyone" mean? It seems like that term invites something like the Russell paradox.

--
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/CANpA1Z2VBh4dGHi-wFQivdx_OhGoFuNGvXWe1hMk3K-A0HvF6g%40mail.gmail.com.

--
Charlie Landau
he/him/his (Why Pronouns Matter)

--
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/80a4262a-8be7-905d-f325-4036418ba1b9%40charlielandau.com.

--

  Cheers,
  --MarkM