Notices by Christine Lemmer-Webber (cwebber@octodon.social), page 17

@kaniini I realize that most users won't see this distinction, but it's *very important that implementors see it*.

Mark Miller will be talking quite a bit about this in his keynote, but for now

- Horton: http://www.erights.org/elib/capability/horton/
- Not One Click For Security (a paper about an ocap user interface discussing the ideas I described called ScoopFS) https://www.hpl.hp.com/techreports/2009/HPL-2009-53.html

@kaniini So what's the equivalent for ocaps? I wrote about it here: https://w3c-ccg.github.io/zcap-ld/#relationship-to-vc

Eva is deciding about whether to hire Alice as a sysadmin; in making that decision, she's reasoning about Alice's identity. Once hires her, she hands Alice an ocap. The *system* does not care who has that ocap upon any invocation, just whether it is valid, but it does log for Eva's information that the ocap being used is the one given to Alice. If Eva sees Alice misuses it, she revokes that ocap.

@kaniini "Reasoning about identity" and ocaps is a bit like side-effects and haskell. Haskell technically needs to work *with* side effects, or its programs would be unable to do anything interacting with the outside world. Similarly, ocaps need a starting and ending place for identity. The way haskell solves this is through the IO monad; it is like a beautiful city of computation, but a truck drives in from one side of the city with input and out the other side of the city with output (cotd)

@kaniini There will always be a trust assertion indeed.

But it's important to recognize where the trust assertion shifts with ocaps; the identity of the peer within the *ocap component* is not checked at the time of receipt. However, through allowing for revocation and accountability, we have a mechanism that composes with the ocap stuff to reason about identity (but we do not make a "value judgement" in the ocap infrastructure, we leave tools so our users can do that)

@kaniini I realize that most users won't see this distinction, but it's *very important that implementors see it*.

Mark Miller will be talking quite a bit about this in his keynote, but for now

- Horton: http://www.erights.org/elib/capability/horton/
- Not One Click For Security (a paper about an ocap user interface discussing the ideas I described called ScoopFS) https://www.hpl.hp.com/techreports/2009/HPL-2009-53.html

@kaniini So what's the equivalent for ocaps? I wrote about it here: https://w3c-ccg.github.io/zcap-ld/#relationship-to-vc

Eva is deciding about whether to hire Alice as a sysadmin; in making that decision, she's reasoning about Alice's identity. Once hires her, she hands Alice an ocap. The *system* does not care who has that ocap upon any invocation, just whether it is valid, but it does log for Eva's information that the ocap being used is the one given to Alice. If Eva sees Alice misuses it, she revokes that ocap.

@kaniini "Reasoning about identity" and ocaps is a bit like side-effects and haskell. Haskell technically needs to work *with* side effects, or its programs would be unable to do anything interacting with the outside world. Similarly, ocaps need a starting and ending place for identity. The way haskell solves this is through the IO monad; it is like a beautiful city of computation, but a truck drives in from one side of the city with input and out the other side of the city with output (cotd)

@kaniini There will always be a trust assertion indeed.

But it's important to recognize where the trust assertion shifts with ocaps; the identity of the peer within the *ocap component* is not checked at the time of receipt. However, through allowing for revocation and accountability, we have a mechanism that composes with the ocap stuff to reason about identity (but we do not make a "value judgement" in the ocap infrastructure, we leave tools so our users can do that)

mood today

daily clay friend

Nice! #Pixelfed and #WordPress are now #federated! 😍