Re: Renaming the OCAP-LD spec... (was: Renaming Object Capabilities...)

On 11/8/18 11:05 PM, Mark Miller wrote:
> No, I don't mind a different name if the name is trying to draw 
> attention to a distinction.

Great! We agree on the foundation for the discussion.

I'd guess that most on the mailing list agree with this foundation - the
name should draw attention to a distinction while not completely
breaking one's ability to discover the greater ecosystem of object
capabilities. Our requirement is that it's also something that doesn't
cause confusion w/ executive-level technical folks / customers.

So, now let's define the distinction and scope it more narrowly. As far
as scope is concerned, let's narrow the scope to changing the name of
the CCG specification. We know at least these distinctions with general
object-capabilities are true:

1. It takes advantage of Linked Data to identify and express
   the capability, the invoker, caveats, and other things.
2. It uses the certificate model.

Arguably, these things are also true about the spec we're creating:

3. These capabilities are not meant to be enforced by a
   programming language. That is, these are not enforced at the
   programming language / interpreter level.
4. These capabilities are intended to almost always be used in
   networked, distributed/decentralized systems.

Chris, are there any other distinctions between general
object-capability systems and the specific one defined in the
specification? Anyone else, thoughts on other distinctions?

-- manu

PS: I'd also like to acknowledge all of the very good points that Joe
made as they get to the heart of the issue when it comes to
communicating this stuff w/ customers that care less about the details
of the tech and more about what the tech does for them.

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches

Received on Friday, 9 November 2018 21:06:41 UTC