YACS (Yet Another Capability System)

[Alan Karp]

https://blog.ceramic.network/capability-based-data-security-on-ceramic/

According to the blog post it's zcap-ld for the blockchain.  There's a link in the document to more information.

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

[Randy Farmer]

Here's the rationale text:

"while both zCAP-LD and UCAN could be serialized as IPLD objects, they use signature schemes that are not easily compatible with the blockchain wallets primarily used for authentication amongst Ceramic community developers and throughout the broader Web3 ecosystem. Therefore, we decided to pull elements from each and create a new format, CACAO (Chain Agnostic CApability Object)."

This makes me wonder two things:

1. What do you all think of the CAO acronym, instead of our older oCap lexical chain?
2. In "Web3" are wallets being treated as people/profiles? That's what this kinda looks like to me. :-P

 

[Alan Karp]

I wrote up a set of access control use cases, https://docs.google.com/document/d/1Jr1MM6Sjfj4f2Y9JjJLOsAxTv2TYNuE_Ck0kMuI589I/edit#, that includes a sidebar on question 1.  I don't like the CAO terminology because it implies the use of blockchain.

As for question 2, these wallets are being used much in the way people have been using certificate authorities, to tie a public key to a person or organization when they talk about signing with "your" key.

--------------
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/5fc3ebe5-3c3a-9369-8b75-c78263ed4002%40pobox.com.

[John K]

On 2/22/22 15:13, Alan Karp wrote:

I wrote up a set of access control use cases, https://docs.google.com/document/d/1Jr1MM6Sjfj4f2Y9JjJLOsAxTv2TYNuE_Ck0kMuI589I/edit#, that includes a sidebar on question 1.  I don't like the CAO terminology because it implies the use of blockchain.

What is the real difference between your two described concepts: "access token" and "access control list"?

For example. If I show up at the White House, my "name" could be seen acting as a bearer token - the holder of that name is allowed access.If someone else shows up and uses my name, they might be allowed access.

If, however (using your second example) I hold a "ticket" to the show (another bearer token), the recipient of the token will likely want to verify that the token was issued by a valid issuer. One way they might do that is to ask the issuer "did you issue this token", and typically this would be done by the issuer checking a list of tokens (which looks very much like an ACL "tokens that I issued" -> "people I have granted access to your site").

In both cases, some authentication might be used, to "prove my identity" (bind the token to "me", or prove it's "me" on the ACL).

Cheers,

- johnk

As for question 2, these wallets are being used much in the way people have been using certificate authorities, to tie a public key to a person or organization when they talk about signing with "your" key.

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

On Tue, Feb 22, 2022 at 10:59 AM Randy Farmer <randy....@pobox.com> wrote:

Here's the rationale text:

"while both zCAP-LD and UCAN could be serialized as IPLD objects, they use signature schemes that are not easily compatible with the blockchain wallets primarily used for authentication amongst Ceramic community developers and throughout the broader Web3 ecosystem. Therefore, we decided to pull elements from each and create a new format, CACAO (Chain Agnostic CApability Object)."

This makes me wonder two things:

1. What do you all think of the CAO acronym, instead of our older oCap lexical chain?
2. In "Web3" are wallets being treated as people/profiles? That's what this kinda looks like to me. :-P

 

On 2/21/2022 10:18 AM, Alan Karp wrote:

https://blog.ceramic.network/capability-based-data-security-on-ceramic/

According to the blog post it's zcap-ld for the blockchain.  There's a link in the document to more information.

--------------
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/5fc3ebe5-3c3a-9369-8b75-c78263ed4002%40pobox.com.

--
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/CANpA1Z0sS2jr-6P8iaKw%3D1ORQmETQHDLZVm8JZLbzuO%2BjxLvQA%40mail.gmail.com.

[Alan Karp]

On Tue, Feb 22, 2022 at 12:38 PM John K <stable.p...@gmail.com> wrote:

What is the real difference between your two described concepts: "access token" and "access control list"?

For example. If I show up at the White House, my "name" could be seen acting as a bearer token - the holder of that name is allowed access.If someone else shows up and uses my name, they might be allowed access.

I'm being pretty informal in this document, so "your name" should be read as proof of your identity.  The key point is that the information you are providing is specific to you, not the venue. 

If, however (using your second example) I hold a "ticket" to the show (another bearer token), the recipient of the token will likely want to verify that the token was issued by a valid issuer. One way they might do that is to ask the issuer "did you issue this token", and typically this would be done by the issuer checking a list of tokens (which looks very much like an ACL "tokens that I issued" -> "people I have granted access to your site").

In contrast to the previous example, the information you provide is per venue and is not specific to you.

In both cases, some authentication might be used, to "prove my identity" (bind the token to "me", or prove it's "me" on the ACL).

A capability is an unforgeable, transferable permission to use the thing it designates.  Hybrid systems, such as you describe, e.g., Li Gong, tie use of the capability to the identity it was issued to.  Unfortunately, these systems lose the "transferable" property if they use the identity as part of making the access decision.  Virtually all such attempts to block delegation are futile because people will share credentials.  (Using the identity for audit purposes is fine, e.g., Horton.)

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

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/5babb4dd-0a7d-a309-3dc8-9aaec0432cf2%40gmail.com.

[Danny O'Brien]

So Ceramic and Fission (one of the alternatives that was mentioned) are both pretty close to the IPFS/Filecoin ecosystem (the IPLD standard CACAO's would be expressed in is part of the IPFS stack).

Would it make sense to get everybody in a (virtual) room to thrash this out? Is it relevant to Spritely, Agoric, Cosmos and/or Cap'n Proto's work?

--
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/5fc3ebe5-3c3a-9369-8b75-c78263ed4002%40pobox.com.

--

Sent from my phone

[Terry Hayes]

The difference is that the check is not "is this whom I issued access to", but "is this token a valid access token".

Yes, the White House check is using your name as an access token, but it is not transferable or delegatable.  You are correct, in both cases the token needs to be validated.

Terry

On Tue, Feb 22, 2022 at 12:38 PM John K <stable.p...@gmail.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/5babb4dd-0a7d-a309-3dc8-9aaec0432cf2%40gmail.com.