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

[Kevin Reid]

On Wed, Sep 7, 2022 at 9:46 AM Alan Karp <alan...@gmail.com> 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?

I would just call the read capability "public" or "published" or "well-known".

It might be good to have a term for a situation where the service itself makes it public (e.g. serving both <https://myblog.example/>, a human-readable URL with no syntactic position for a capability, whereas <https://myblog.example/c/<capability bits go here>/>), but I don't know of an established term for such a system.

[Raoul Duke]

seems like "universal X access" could be a term that means you do not need to supply an X cap when Xing?

[Matt Rice]

FWIW, in the model I use where the former are a part of a projective
space (with red lines), and the latter a projective space (with green
lines), I just call them by color.

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

[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

[Bill Frantz]

On Sep 7, 2022, at 13:07:23, Raoul Duke <rao...@gmail.com> wrote:

seems like "universal X access" could be a term that means you do not need to supply an X cap when Xing?

I a capability system, a capability is how you name a resource. So of course, you have to supply a capability.

Now we can talk about a system which supports more than one form of capability. One that is supposed to reference a resource with security properties other that public-read should be unguessable. On the other hand, a capability which is represented by the string, “Joe’s Blog” could also be supported.

Cheers - Bill

[Raoul Duke]

so the public url yhen?

--
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/C302083D-2856-495F-A349-9ABDF9E1D181%40pwpconsult.com.

[Alan Karp]

On Wed, Sep 7, 2022 at 6:18 PM Raoul Duke <rao...@gmail.com> wrote:

so the public url yhen?

That leaves out certificates as capabilities.

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

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

 

--
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]

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.

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

On Thu, Sep 8, 2022 at 11:47 AM David Nicol <david...@gmail.com> wrote:

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.

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

[Matt Rice]

I think it is a bit nuanced,

Doesn't this depend on whether the thing is sensory[1], e.g. if Alan's
blog is running on a capability system capable of confinement,
and it is readable from 'all', and has a sensory version of it, that
sensory version could be reachable from within a confined space,
but his blog cannot be written within that space and then shared
outside it (obviously).

1: Using Norm's description of sensory,
http://www.cap-lore.com/CapTheory/KK/LaySense.html

The coloring I mentioned is not entirely unrelated...

> 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-_AD5DJyd%3D6%3DKV-cY4ax_v4-wJJhECyPWtH9N6UO%2BGdggLYw%40mail.gmail.com.

[Mark S. Miller]

No. Sensory makes confinement more expressive. But disjointness is enough to confine.

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CACTLOFpYhZ_cxY0eE34-hb7Yzmpsj9oDtO%3DZ2XCSha7ZnteDWQ%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Matt Rice]

I believe I see your point, even if there exists a confined space
something public is reachable from,
it is not reachable from *all* of them. I was basically reacting to
"all who are not confined", which
I read as excluding confined spaces with Sensory, where it might be
reachable. But i would agree
with 'All who are not reachable'...

Apologies, it appears I may have forgotten to "reply to all" in my
first response...

> To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAK5yZYi6Hsw9LqjJuO-8W%3DP08FM9DeYAbc29iLexgqaVxEiMPQ%40mail.gmail.com.

[Matt Rice]

On Fri, Sep 9, 2022 at 10:23 PM Matt Rice <rat...@gmail.com> wrote:
>
> I believe I see your point, even if there exists a confined space
> something public is reachable from,
> it is not reachable from *all* of them. I was basically reacting to
> "all who are not confined", which
> I read as excluding confined spaces with Sensory, where it might be
> reachable. But i would agree
> with 'All who are not reachable'...

er... all who are reachable.