Opaque vs non-opaque capabilities

[Alan Karp]

GNAP, which is really OAuth 3, is about to decide to use opaque tokens as capabilities, ala E's sturdy refs, as opposed to non-opaque tokens, such as zcap-ld.  The fact that clients don't need to understand the token format is a huge advantage.  The downside is that there is no offline delegation; you have to do a token exchange with the issuer.

How important is offline delegation?  

Can you come up with important use cases where there isn't an adequate workaround, such as doing the exchange ahead of time or setting up a facet?

Are there other advantages to non-opaque tokens?  One we know of is the ability to know that the token authorizes what you think it does.

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

[Mark S. Miller]

Depending on your definitions, I'd say that 

https://www.youtube.com/watch?v=7u0yVJjBBek&list=PLzDw4TTug5O0ywHrOz4VevVTYr6Kj_KtW

does offline delegation opaquely, using c-list indexes rather than target identities.

--
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/CANpA1Z3OUp1xZf%3DWfaFnwNREoh-zy%3DahNZmXG1U-x_R0v%2BZLog%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Alan Karp]

Mark S. Miller <eri...@gmail.com> wrote:

Depending on your definitions, I'd say that 

https://www.youtube.com/watch?v=7u0yVJjBBek&list=PLzDw4TTug5O0ywHrOz4VevVTYr6Kj_KtW

does offline delegation opaquely, using c-list indexes rather than target identities.

Alice is giving Bob access to Carol.  Did I get that right?  My understanding is that Bob can't access Carol until after Carol has heard from Alice about the delegation.  I would not call that offline delegation.  Carol does not have to hear about the delegation from Alice with certificate systems, such as zcap-ld.  That's what I mean by offline delegation.

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

[Mark S. Miller]

In SPKI and all SPKI-like systems, when Bob accesses Carol, VatB sends to VatC a certificate chain that includes the certificate by which VatA authorized VatB to access Carol. Here, the "extra" message in the certificate chain is a message "from" VatA to VatC telling VatC that VatB is authorized to call Carol. "from" is in scare quotes because VatA doesn't need to send this message to VatC. In the scenario, VatA relays this message to VatC by sending it to VatB to deliver to VatC. VatC does not need to receive this until VatB actually accesses Carol. So VatB can just include this authorization in the overall packet that also contains his accessing Carol. Since the extra message only needs to be understood by VatA and VatC, in a system capable of secrets (pretty much anything except blockchains), that extra message can be encrypted so VatB cannot read it, but would still convey it bundled with his access request.

--

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

--

  Cheers,
  --MarkM

[Alan Karp]

Mark S. Miller <eri...@gmail.com> wrote:

In SPKI and all SPKI-like systems, when Bob accesses Carol, VatB sends to VatC a certificate chain that includes the certificate by which VatA authorized VatB to access Carol. Here, the "extra" message in the certificate chain is a message "from" VatA to VatC telling VatC that VatB is authorized to call Carol. "from" is in scare quotes because VatA doesn't need to send this message to VatC. In the scenario, VatA relays this message to VatC by sending it to VatB to deliver to VatC. VatC does not need to receive this until VatB actually accesses Carol. So VatB can just include this authorization in the overall packet that also contains his accessing Carol. Since the extra message only needs to be understood by VatA and VatC, in a system capable of secrets (pretty much anything except blockchains), that extra message can be encrypted so VatB cannot read it, but would still convey it bundled with his access request.

Exactly.  I say it is an offline delegation because Alice can decide to delegate after her last contact with Carol.  I don't believe that's the case in the example in the video.  Also, the certificate cannot be opaque because Alice must know how to construct one.

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

[Mark S. Miller]

It is case. At 32:59 https://youtu.be/7u0yVJjBBek?t=1979 the message on the left labeled "A->C1" is actually carried as extra opaque payload in the packed sent from VatB to VatC, along with the "B1->C1" message that Bob sent to Carol. The curved red line indicates this certificate chain, by which the incoming message on the right includes the incoming message (perhaps confusingly) shown on the left.

 

  Also, the certificate cannot be opaque because Alice must know how to construct one.

Then I don't understand what opaqueness is at stake. What is opaque to whom?

 

--------------
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/CANpA1Z2fMHnZG6cPDjF3BOFC2JgkDefJT4%2B4C8%2BcWsFRL%3Djr-A%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Alan Karp]

Mark S. Miller <eri...@gmail.com> wrote:

It is case. At 32:59 https://youtu.be/7u0yVJjBBek?t=1979 the message on the left labeled "A->C1" is actually carried as extra opaque payload in the packed sent from VatB to VatC, along with the "B1->C1" message that Bob sent to Carol. The curved red line indicates this certificate chain, by which the incoming message on the right includes the incoming message (perhaps confusingly) shown on the left.

 

  Also, the certificate cannot be opaque because Alice must know how to construct one.

Then I don't understand what opaqueness is at stake. What is opaque to whom?

I think explaining "opaqueness" will answer both your questions.  The following terminology comes from the OAuth and GNAP world.  There is a resource server, RS, that a client contacts when it wants to use a resource.  There is an authorization server that the client contacts to get an access token (capability) that it presents with its request to the RS.  The RS forwards each request to the AS, and the AS tells the RS whether it should honor it.  

With opaque tokens, the AS could start by representing tokens as GUIDs.  Each GUID would point to an entry in a map that says what permissions are being authorized.  After a while, the AS could decide to start using 64-bit random numbers for the tokens.  Since the tokens are opaque, everybody else just treats them as a bag of bits and doesn't need to change a line of code.

Things are more complicated with non-opaque tokens.  The zcap-ld spec shows how much everyone needs to agree to.  Even the encryption needed to pass the extra message through Bob is an additional standard that needs agreement.

The question is whether we give up anything important by using opaque tokens.  I thought that was offline delegation, but now I'm not so sure.

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

[Mark S. Miller]

What is made opaque? Who is it supposed to be opaque to? What entity in the granovetter introduction is supposed to not know something that the opaqueness would prevent them from knowing? What extra thing would they know in the introduction explained in my talk, if the "A->C1" message were encrypted so VatB cannot read it? If possible, please answer in terms of our standard players, Alice, Bob, Carol, VatA, VatB, and VatC.

--

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/CANpA1Z0SM_h%3DdfPBm_WyEsm8uOWY3Px8UfJyBp0c7gQ_kKgk0g%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Alan Karp]

Mark S. Miller <eri...@gmail.com> wrote:

What is made opaque? Who is it supposed to be opaque to? What entity in the granovetter introduction is supposed to not know something that the opaqueness would prevent them from knowing? What extra thing would they know in the introduction explained in my talk, if the "A->C1" message were encrypted so VatB cannot read it? If possible, please answer in terms of our standard players, Alice, Bob, Carol, VatA, VatB, and VatC.

I can't answer solely in the standard terminology because of the extra player, the AS, but I think I can come close.

Say that Alice, the delegating client, has previously obtained a capability (access token) granting permission to invoke to Carol, the RS.  Alice wishes to delegate that access to Bob, the delegatee client.  With opaque tokens, which I'll try to explain below, Alice presents her capability to the AS, which doesn't enter into our standard terminology, and gets a new capability, perhaps with fewer permissions (scopes), which she sends to Bob.  Bob can now use that capability to invoke Carol.  When Bob invokes Carol, she forwards the request to the AS.  The AS validates that the capability Bob used in the invocation authorizes what he is asking to do and tells Carol to honor the request.

To every participant other than the AS an opaque token is just a bag of bits.  Everyone other than the AS just passes the token through unexamined.  To them it has no useful content or even structure.  It might have been created by a random number generator; it might be the encryption of a digital certificate; it might be a counting integer.  The AS constructs the token, and the AS interprets it.  The token is "opaque" to everyone else.

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

[Mark S. Miller]

That's cheating. You've introduced a mutually trusted fourth party, the AS. In a peer-to-peer network of vats, how many ASes are there? Which vat is vulnerable to which AS? What if there is no one AS that VatA, VatB, and VatC mutually trust?

--

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/CANpA1Z3006OYZD%2BjWjp_JM25JZCbSpOnvsW%2BzHu4kMRNLtEvkQ%40mail.gmail.com.

[Alan Karp]

Mark S. Miller <ma...@agoric.com> wrote:

That's cheating. You've introduced a mutually trusted fourth party, the AS. In a peer-to-peer network of vats, how many ASes are there? Which vat is vulnerable to which AS? What if there is no one AS that VatA, VatB, and VatC mutually trust?

If anyone cheated, it was the GNAP people, not me :)

As for the trust relationships, that was a point of confusion that the group has now clarified.  The confusion turned out to be just a matter of terminology.  People were talking about "the AS" without being explicit about which one they were referring to.

The RS trusts an AS, call it RS-AS, to hand out access tokens based on the RS's policy and to validate those tokens when the RS receives requests.  A resource owner (RO), a new term I tried to spare you, can have its own AS, call it AS-RO, to delegate capabilities based on the RO's policy and to validate requests the RO might receive.  Each participant is only vulnerable to an AS of its choosing.  The RS can also act as its own AS.  The two can even run on the same physical machine.  The (poor) analogy is that the AS is the vat to the RS's object in the sense that the RS depends on the AS to tell it which requests to honor.

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

[Mark S. Miller]

I propose that we can, without loss of generality, combine AS-C and RS-C into VatC and consider them as a unit. If we do, then what remaining opacity are they providing, and who is being denied knowledge of what? If it doesn't make a difference in the knowledge of the agents, then it is not a useful opacity.

--

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

[Alan Karp]

Mark S. Miller <ma...@agoric.com> wrote:

I propose that we can, without loss of generality, combine AS-C and RS-C into VatC and consider them as a unit. If we do, then what remaining opacity are they providing, and who is being denied knowledge of what? If it doesn't make a difference in the knowledge of the agents, then it is not a useful opacity.

AS-C+RS-C=VatC is a fair way of understanding GNAP. 

An opaque token is like a Swiss number in E.  Now imagine that the vat holding the corresponding object had an API that would give you back a new Swiss number for a facet of that object.  Imagine further that you didn't need to set up a live ref to invoke the object; you could just use the Swiss number.  That's the way opaque access tokens work in GNAP.

A zcap-ld certificate is not an opaque token.  A zcap-ld capability has structure that Alice must understand when she wants to delegate it to Bob. 

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

[Mark S. Miller]

Clarity, thanks!

My protocol (thanks to you!) uses c-list entries, not swiss nums. It is interesting to compare them for opacity. In some ways swiss nums are more opaque. In other ways, c-indexes are.

Is this the only real difference in opacity?

--

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/CANpA1Z2LVn%2BtJCD686ee4JJqYrW6U-1Up%2BNpPSXOC1-JN3tmxQ%40mail.gmail.com.

[Alan Karp]

Mark S. Miller <ma...@agoric.com> wrote:

Clarity, thanks!

My protocol (thanks to you!) uses c-list entries, not swiss nums. It is interesting to compare them for opacity. In some ways swiss nums are more opaque. In other ways, c-indexes are.

Is this the only real difference in opacity?

The GNAP opaque tokens are more like the fragment in Tyler's web keys in that there's one c-list for all connections rather than a separate c-list for each connection.  (A distinction I make in my talk on unforgeable distributed capabilities.)  It's as if you use a sturdy ref directly rather than creating a live ref.

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

[Mark S. Miller]

I think we're saying the same thing. Tyler's fragments are swiss numbers. My conjecture is that the opacity difference is exactly swiss numbers vs c-list indexes. All the other differences in the protocols might not matter. The opacity differences between swiss numbers and c-list indexes are interesting. Neither dominates the other.

But I don't see how Tyler's fragments (or swiss numbers) c-list for all connections. Each one represents an object hosted by some vat. To have the right to be (the host of) the designated object, the Vat must also know the private key that it associated with that swiss number. Any other vat could export a different object with a different VatID but reusing a swiss number that they came to know as a client of another vat. If we think of all vats jointly forming a virtual global swissnum-indexed c-list, then how is it that the same swiss number can designate two separate objects without anyone getting misled.

Rather, Tyler's fragments (or swiss numbers) were c-list indexes into a per-hosting-vat clist. CapTP's c-list indexes are indexes into a per connection c-list.

--

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/CANpA1Z1iuxzadTTPiO4pB7BOKvvxVbwr3fE6kNNO59FO3pH3%2BA%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Alan Karp]

Mark S. Miller <eri...@gmail.com> wrote:

Rather, Tyler's fragments (or swiss numbers) were c-list indexes into a per-hosting-vat clist. CapTP's c-list indexes are indexes into a per connection c-list.

That's what I was trying to say.

Now to my original question.  How important is the ability to do attenuated delegation locally the way you would with zcap-ld?

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

[Mark S. Miller]

Can you explain this property of zcap-ld in terms of our standard players and building on our standard scenario?

--

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

[Alan Karp]

Mark S. Miller <ma...@agoric.com> wrote:

Can you explain this property of zcap-ld in terms of our standard players and building on our standard scenario?

Alice has a zcap authorizing her to invoke Carol.  Alice asks Bob for a public key, which he can create on the spot, and creates a new zcap issued to that public key.  Alice sends the new zcap to Bob who can use it to invoke Carol.  Carol can verify that Bob has the requested permission solely from the contents of the zcap Bob used.

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

[Mark S. Miller]

Does this scenario have attenuation? If not, what is different about it and what question are we asking?

--

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/CANpA1Z3DwLcFi6TXMXX3L0yqpbXKuD%2BWbpOxdiROUAHXnxKh8w%40mail.gmail.com.

[Alan Karp]

Mark S. Miller <ma...@agoric.com> wrote:

Does this scenario have attenuation? If not, what is different about it and what question are we asking?

Yes.  Alice can specify a subset of the permissions in her zcap when she creates the zcap to give to Bob.  It's just the way SPKI does it.

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

[Mark S. Miller]

Who defines the sublanguage Alice uses to express attenuations of the kind of thing that Carol is?

Alice then writes an attenuation in that sublanguage. Presumably VatC or Carol interpret it?

Btw, thanks for going through this with me. This is exactly what I've needed to translate concepts between the two systems.

--

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

[Alan Karp]

Mark S. Miller <ma...@agoric.com> wrote:

Who defines the sublanguage Alice uses to express attenuations of the kind of thing that Carol is?

That's part of the delegation API.  In OAuth, and I presume GNAP, the "scopes" are specified as strings understood by the delegator and the validator of the request. 

Alice then writes an attenuation in that sublanguage. Presumably VatC or Carol interpret it?

VatC. 

Btw, thanks for going through this with me. This is exactly what I've needed to translate concepts between the two systems.

My pleasure.

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

[Raoul Duke]

since iama visual thinker i hope somebody some day diagrams such things for posterity :-)

[Alan Karp]

There are pictures in the draft GNAP spec, https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/?include_text=1.

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

On Fri, Mar 19, 2021 at 10:19 PM Raoul Duke <rao...@gmail.com> wrote:

since iama visual thinker i hope somebody some day diagrams such things for posterity :-)

--

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/CAJ7XQb4Dn_cOaNReFsCH_O634u-e9M9%2BT1PORsBZpthvNYskyw%40mail.gmail.com.

[Mark S. Miller]

No Granovetter diagrams!

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z2Sonn%3D5%2BJ_fTt_2sHZvuMTX3Z6fBDdqLqDso8m9%3DZ3Xg%40mail.gmail.com.

[Mark S. Miller]

On Fri, Mar 19, 2021 at 10:17 PM Alan Karp <alan...@gmail.com> wrote:

Mark S. Miller <ma...@agoric.com> wrote:

Who defines the sublanguage Alice uses to express attenuations of the kind of thing that Carol is?

That's part of the delegation API.  In OAuth, and I presume GNAP, the "scopes" are specified as strings understood by the delegator and the validator of the request. 

Alice then writes an attenuation in that sublanguage. Presumably VatC or Carol interpret it?

VatC. 

Then this attenuation is what Norm Hardy calls a "foreseen facet". If Carol is a file, she may provide a `readOnly()` method for getting read only attenuated access to that file. Then

Alice says:

   bob <- foo(carol <- readOnly()) // in E

or

   E(bob).foo(E(carol).readOnly()) // in distributed SES

An unforeseen facet is when the author of Carol does not foresee the need for that particular attenuation, so Alice must construct it on her own

   bob <- foo(readOnly(carol)) // in E

   E(bob).foo(readOnly(carol)) // in distributed SES

There was no equivalent of unforeseen attenuation in SPKI-like systems I know. Any exceptions? GNAP?

 

Btw, thanks for going through this with me. This is exactly what I've needed to translate concepts between the two systems.

My pleasure.

--------------
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/CANpA1Z1TyVqSTkJMVdAH4Lv7rbVsojXcpCrvD%2Bz1OmqAsuXpzw%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Christopher Lemmer Webber]

Mark S. Miller writes:

> On Fri, Mar 19, 2021 at 10:17 PM Alan Karp <alan...@gmail.com> wrote:
>
>> Mark S. Miller <ma...@agoric.com> wrote:
>>
>>> Who defines the sublanguage Alice uses to express attenuations of the
>>> kind of thing that Carol is?
>>>
>>
>> That's part of the delegation API. In OAuth, and I presume GNAP, the
>> "scopes" are specified as strings understood by the delegator and the
>> validator of the request.
>>
>>>
>>> Alice then writes an attenuation in that sublanguage. Presumably VatC or
>>> Carol interpret it?
>>>
>>
>> VatC.
>>
>
> Then this attenuation is what Norm Hardy calls a "foreseen facet". If Carol
> is a file, she may provide a `readOnly()` method for getting read only
> attenuated access to that file. Then
>
> Alice says:
> bob <- foo(carol <- readOnly()) // in E
> or
> E(bob).foo(E(carol).readOnly()) // in distributed SES
>
> An unforeseen facet is when the author of Carol does not foresee the need
> for that particular attenuation, so Alice must construct it on her own
>
> bob <- foo(readOnly(carol)) // in E
> E(bob).foo(readOnly(carol)) // in distributed SES
>
> There was no equivalent of unforeseen attenuation in SPKI-like systems I
> know. Any exceptions? GNAP?

I've never heard the terms unforeseen vs foreseen facets before. This
is a really useful phrase / distinction!

It seems clear to me that zcap-ld facets are foreseen. Most unforeseen
facets tend to be proxy approaches, with the extra costs between.

But what about the "certificate ocaps where the attenuation is in code"
point of view? What's interesting about these is that they're
unforeseen but without the proxy costs traiditionally associated with
unforeseen approaches.

[Mark S. Miller]

Yes! That was the focus of capCert. But it raises the tricky matter of sending non terminating code. What are your thoughts on that?

--

  Cheers,
  --MarkM

[Alan Karp]

Mark S. Miller <ma...@agoric.com> wrote:

No Granovetter diagrams!

The diagrams associated with UMA (User Managed Access) have Granovetter-like figures, but the extra components (AS) obscure things. 

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

[Alan Karp]

Mark S. Miller <eri...@gmail.com> wrote:

Then this attenuation is what Norm Hardy calls a "foreseen facet". If Carol is a file, she may provide a `readOnly()` method for getting read only attenuated access to that file. Then

Alice says:

   bob <- foo(carol <- readOnly()) // in E

or

   E(bob).foo(E(carol).readOnly()) // in distributed SES

An unforeseen facet is when the author of Carol does not foresee the need for that particular attenuation, so Alice must construct it on her own

   bob <- foo(readOnly(carol)) // in E

   E(bob).foo(readOnly(carol)) // in distributed SES

There was no equivalent of unforeseen attenuation in SPKI-like systems I know. Any exceptions? GNAP?

The method names are part of the API, so there is no escaping the fact that all participants must know what they mean.  In your example, Alice would have a token with "read" and "write" scopes.  The new token would have just the "read" scope.  There's no need to set up a specific facet.  In addition, it's easier to deal with combinations of permissions.  Say that Alice has CRUD permissions.  Everyone has to understand what create, read, update, and delete mean, but nobody has to create a facet for all the combinations, RU, vs. CD vs.RD, etc.  In E you'd have to set up a facet for each combination.

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

[Mark S. Miller]

In practice that's actually easier. Only some combinations make sense. The author of Carol is in the best position to do that abstraction design.

 

--------------
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/CANpA1Z2NZ_7SU22njzEF3xA_rVRp%3Du0SwX7P%2Bs8e9bP8Dud%3D3A%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Alan Karp]

Mark S. Miller <eri...@gmail.com> wrote:

In practice that's actually easier. Only some combinations make sense. The author of Carol is in the best position to do that abstraction design.

 

That's not true in the enterprise space, where applications have hundreds of methods.  Grouping them ahead of time will result in overprovisioning, which is what people do to avoid role explosion in RBAC. 

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

[Jonathan S. Shapiro]

On Fri, Mar 19, 2021 at 1:59 PM Alan Karp <alan...@gmail.com> wrote:

GNAP, which is really OAuth 3, is about to decide to use opaque tokens as capabilities, ala E's sturdy refs, as opposed to non-opaque tokens, such as zcap-ld.  The fact that clients don't need to understand the token format is a huge advantage.  The downside is that there is no offline delegation; you have to do a token exchange with the issuer.

How important is offline delegation?  

Can you come up with important use cases where there isn't an adequate workaround, such as doing the exchange ahead of time or setting up a facet?

I'm not up to speed on GNAP, but does it supersede the id token and refresh token notions of OAuth2.0/2.1?  What about the id token refresh protocol and the client secret?

If not, then I think offline delegation is problematic in two regards. The first is that both the refresh token and the client secret are highly sensitive, and you can't do id token refresh without them. Given the number of ways systems can and do get compromised, I'd be very concerned about a protocol that expanded the exposure of these two tokens by passing them back and forth offline.

Jonathan

[Alan Karp]

Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

I'm not up to speed on GNAP, but does it supersede the id token and refresh token notions of OAuth2.0/2.1?  What about the id token refresh protocol and the client secret?

I'm no expert on the protocol, either.  I have to check the spec, https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/?include_text=1, every time.

The client secret is gone, and the token refresh is far simpler.  Instead of having a separate refresh token, GNAP does something they call token rotation.  The client submits the expired token in a request signed by the same key used when the token was issued to it.  If everything checks out, the client gets a new token.

If not, then I think offline delegation is problematic in two regards. The first is that both the refresh token and the client secret are highly sensitive, and you can't do id token refresh without them. Given the number of ways systems can and do get compromised, I'd be very concerned about a protocol that expanded the exposure of these two tokens by passing them back and forth offline.

Are you using the term "offline" differently than I am?  I would say that something like SPKI or zcap-ld allows offline delegation, because the delegation can be done without communicating with anyone else.  Delegation can only be done "online" with opaque tokens.  Because the delegator has no way to construct a new token, it must contact someone else to get one. 

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

[Christopher Lemmer Webber]

I still don't have a good answer personally yet... it seems like we'd
have to either go the "more limited language but with some ahead-of-time
bounding guarantees" approach or the gas approach, or a hybrid of the
two.

Thinking about it out loud, I'm not sure gas can be escaped anymore for
a CapCert type approach. At one point it probably could be, but even
programs with bounding guarantees, if used successively, could be used
to offload something like bitcoin mining when allegedly they were there
for attenuation originally.

If I'm right about that, there seems to be no escaping gas... we are
merely left with gas with ahead-of-time guarantees but a restricted
language or an unrestricted but possibly fails-at-attenuation-time
approach. But running out of gas appears to merely mean "full
attenuation", so maybe we really don't need to spend too much brain
energy on the restricted language part if we can't escape gas anyway, at
least not initially. I dunno.

There may be another way to do this that doesn't involve changes to the
captp protocol specifically. A bootstrap object could return a method
that allows for spelserver like behavior, bounded with gas... in such
cases, we could simply send code to be eval'ed as a new actor across the
wire, loaded onto the remote vat. There's no need for special
certificate *anything* in that case either.

With that, we could have code for spawning an actor, but the choice of
whether to spawn locally or remotely could be made dynamically based on
whether or not the bootstrap actor declares an interface that it has
support for remote actor instantiation.

Just thinking out loud...

[Raoul Duke]

could the gas cost real money?

[Christopher Lemmer Webber]

What is "real money"? A shocking number of things become "real money"
even if we try our darndest to make them not so (see many MMORPGs trying
to prevent their in-game economy from bleeding over into the real
economy, and failing).

It should cost something. What, and via what mechanism, is a good
question though.

My personal anticipation is that gas for these kinds of things probably
need to be per-machine. The reason is simple: we want transaction times
and round-trips to be extremely low... *especially* if we want these
because we expect we'll gain performance optimizations.

If a lot of operations are happening at once, it would be best if the
currency was extremely localized and cheap. However, buying into it
(or out of it) could involve "real money". So for instance, a machine
could issue a very lightweight E-style mint. I actually think, even
though the Ode paper says "this doesn't have all the properties of real
money", it has all the properties we need for "extremely local gas".

Think of an 80s-90s video game arcade: you exchange "real money" for
tokens that theoretically only exist within that domain (eg,
Chuck-E-Cheese is a famous example, but many arcades had their own
equivalent system). These tokens, within the domain, feel very
valuable: they open up opportunities for enjoyment within the local
environment, and even opportunities to win prizes in some cases.
(Casinos do this too, but the incentive alignments in casinos are
usually more potentially exploitative than in an arcade... it also turns
out that an arcade is much more equivalent; fools lose their money in
casinos thinking they'll get rich, but kids and teenagers blow through
cash for machine-time enabling tokens knowing full well it's no path to
riches external to that experience.)

So, imagine we extend our bootstrap actor with a few things:

- A "token machine" to get machine-time participation in this "arcade".
Put in a twenty dollar bill, get a handful of local-to-this-arcade
tokens.

- Some "arcade machines" that allow for interesting behavior. One such
example would be the ability to run a sandboxed-eval... but this can
be used for shortening.

Note, a curious feature of some arcades: many would accept both tokens
*or* USD quarters. However, you'd get a *better deal* by using tokens:
you might get six tokens for one dollar, and four quarters for one
dollar, but an arcade machine would accept either one token or one
quarter. (But this makes a lot of sense especially in *our* case:
there's also an extra delay to use a "quarter", because we'd presumably
have to talk to an external mint to verify this is legit.)

This also leads to an interesting experience... maybe you had it, I
certainly did: there might be some tweenagers leaving the arcade, and
they say, "Hey, my parents are making us leave... I don't have time to
play games anymore. I've got fifteen tokens here, count 'em... I'll
give them to you for... how about five bucks? You'd have to spend ten
bucks normally to get these many... but I don't have use for them
anymore, and it looks like you do."

Of course, some arcades would see tweenagers doing the same and might
decide they want in on the action, and offer a similar "exchange back"
option... at a way lower rate than you'd usually find from the tweenager
though...

By the way, once we start adding gas to operations, I think that opens
us up to new classes of "potential vulnerabilities" akin to confused
deputies. We've now separated designation from a kind of authority:
cash in the bank to execute. Similar to the "confused rights
amplifiers" conversation, there's a confused deputy attack where you'd
like to access a resource but you "trick" the other participant into
spending *their* money instead of yours. However, I think the solution
is probably similar to the protection against "confused rights
amplifiers": instead of siphoning from a general tank on demand, have
the gas carried through the system with proper flow:

See:
https://groups.google.com/g/friam/c/94EZip0o4XM/m/XcP-18bjBAAJ
and the associated sketchy image for thoughts on how to start thinking
about this safely and illustrate gas usage on the granovetter diagram.

One thing not covered there: garbage collection finalizers can be used
to siphon money that would never have been spent, held up in a workflow,
back to a general tank. This can prevent money from being lost between
the sofa cushions, so to speak.

- Chris

[Alan Karp]

Interesting comments, Chris.  How do they apply to the opaque/non-opaque question?

--------------
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/87zgyxw107.fsf%40dustycloud.org.

[zaru...@gmail.com]

One idea I came up with last friam was to offer an attenuator function as mobile code.

Such a function would take in an 'opaque' token and an attenuation parameter. It would then return a new 'opaque' token.

This is basically late binding the specification of the tokens to as late as possible in the process.

Though the attenuation parameter must be specified much earlier.

This is for the forseen offline attenuated delegation cases. But it lacks the blame-deniability of online  attenuated delegation where the new token is given directly to the delegatee.

On Friday, 19 March 2021 at 20:59:56 UTC alan...@gmail.com wrote:

GNAP, which is really OAuth 3, is about to decide to use opaque tokens as capabilities, ala E's sturdy refs, as opposed to non-opaque tokens, such as zcap-ld.  The fact that clients don't need to understand the token format is a huge advantage.  The downside is that there is no offline delegation; you have to do a token exchange with the issuer.

How important is offline delegation?  

Can you come up with important use cases where there isn't an adequate workaround, such as doing the exchange ahead of time or setting up a facet?

Are there other advantages to non-opaque tokens?  One we know of is the ability to know that the token authorizes what you think it does.

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