Re: VCs - zCaps / OCap a Discussion

Hi Daniel

the concept of bearer credential is already embedded in the current VC 
spec (section 7.9) so we do not need to redefine it. This would be a 
retrograde step.

I would thus propose to change your definition as below

On 24/12/2020 02:36, Daniel Hardman wrote:
> Alan:
>
> Thank you for the thoughtful answers. I feel like I understand your 
> concern a bit better; it seems that you're worried about VC-based 
> OCAPs having extra fields (an anti-pattern), and about the oddness of 
> fitting 2 fields into 3, because misunderstandings will ensue. Did I 
> summarize you accurately?
>
> I think those are reasonable concerns. To me, a good way to solve them 
> would be to publish a paragraph that says something like this:
>
>     An OCAP is a bearer credential that includes
>     "https:///somewhere.com
>     <http://somewhere.com>//ocap-context.jsonld" in its @context
>     array, that declares one value of its type property to be "OCAP",
>     and that has a single, simple credentialSubject block that looks
>     like this:
>
the id field is missing

the following two fields are present

>     {"resource": "/url_identifying_the_resource/",
>

>     "privilege": ["/privilege_name/"]}. 
>

>     This announces to the world that the bearer of the credential is
>     authorized to access the specified resource with the specified
>     privilege name(s). Privilege names should be defined in an
>     additional JSON-LD @context to clarify their semantics. 
>
Kind regards

David


>
> That's almost it. We still need some cautionary language, and we need 
> to answer your question about delegation. That would require an 
> additional paragraph:
>
>     There is one optional, extra attribute (embodying a second
>     possible RDF triple) in the OCAP's credentialSubject block:
>     provenanceProof. If this field is present, its value is an
>     embedded verifiable presentation of another OCAP that shows how
>     the issuer received authority sufficient to grant the privileges
>     it is extending. This can be used to create delegation chains.
>     Although VCs in general are extensible, adding additional fields
>     or credentialSubjects to an OCAP VC is strongly discouraged, as
>     this undermines the pure authorization semantics that are a
>     defining characteristic of OCAPs.
>
>
> And that's about all. I've essentially written an entire OCAP spec in 
> two paragraphs. There's more that could be said -- examples, 
> implementation guidance, more about the theory of OCAPs -- but the 
> core is just that much. In this approach, OCAPs become verifiable by 
> any stack that can verify VCs, as just a credential type with some 
> constraints. They have all the same signature suites, serialization 
> formats, revocation mechanisms, governance, tribal knowledge, 
> documentation, PR gravitas, and community implementations that VCs do. 
> They don't need a separate spec or separate libraries, and the interop 
> task is minor high-level details, not foundation-level tech.
>
> I believe Orie embodied thinking like this in the OCAPs-as-VCs repo 
> that he hyperlinked. I had a similar idea. I wrote a doc that 
> describes this mechanism (Aries RFC 0104: Chained Credentials 
> <https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0104-chained-credentials/README.md>), 
> and spoke about it at IIW. IIRC you attended the session and gave some 
> really helpful guidance; I rolled some of it into an update to the 
> doc. Now Sam Smith is proposing to generalize the idea of 
> provenanceProof to other problems, allowing an issuer to cite sources 
> for any data (not just authZ data) they put in a VC ("Here's the name 
> and address of the credentialSubject, and here's a provenance proof 
> that shows where I got that info, so you can believe the origin issuer 
> instead of me, the proximate issuer.") This has applications in supply 
> chain, guardianship, and organizational behavior, not just OCAPs. It 
> can also shrink the number of parties that must be trusted in an 
> ecosystem (a crucial goal that we're undervaluing throughout the VC 
> ecosystem), since a valid chain can have any number of unknown 
> intermediaries, as long as its root is known.
>
> What started this whole conversation is that Kaliya asked Sam and me 
> to talk to zCaps proponents because she correctly noted an overlap in 
> the problem we're going after. It is true that we are intending to 
> represent OCAPs as VCs and that this overlaps with the problem domain 
> of zCaps -- but we are also wanting to solve that other data 
> provenance problem, too. And the reason I'm not liking the "give OCAPs 
> a separate spec of their own" answer is that every variation of VC use 
> cases we dream up is going to trigger the same tension. Should VCs be 
> used to give legal testimony -- or should we invent and standardize a 
> new spec for doing that, even though it essentially recapitulates the 
> full content of the VC spec? How about tracking chain of custody in 
> supply chain? How about VCs for voting? Etc. Etc.
>
> Now, I know that you, personally, did not argue that VCs were purely 
> identity oriented. If I've summarized your concerns well, you've just 
> had worries about the narrow case of OCAPs being solved with a broad 
> tool like OCAPs. But your argument has something in common with the 
> "VCs are only for identity" argument: both advocate narrow solutions. 
> I get the wisdom of narrowness. But I don't think it's the optimal 
> tradeoff in this case. Getting the world to adopt decentralized 
> identity is already a huge shift. VCs add another crucial, high-stakes 
> standards-and-interop battle that we must fight. The DID spec is 
> another. And then there are battles about DID methods, blockchain 
> interop, governance, etc. We can only afford to fight so many battles 
> like this, in a given timeframe. When you have a lot of breadth but 
> you target narrow standards, that means you have to have a *lot* of 
> standards. This isn't the right strategy, IMO, when a space is young. 
> Young spaces should have a few broadly applicable standards. Then, 
> years later, when group wisdom and battle scars have accumulated, you 
> produce specialized standards for particular problem domains, when 
> you're confident that the narrowness is justified by the extra 
> precision. That's why I'm not a zCaps supporter; they specialize too 
> early.
>
>
> On Wed, Dec 23, 2020 at 4:59 PM Alan Karp <alanhkarp@gmail.com 
> <mailto:alanhkarp@gmail.com>> wrote:
>
>     Daniel Hardman <daniel.hardman@evernym.com
>     <mailto:daniel.hardman@evernym.com>> wrote:
>
>         Here is the definition of "credentials" as a noun, from Meriam
>         Webster
>         <https://www.merriam-webster.com/dictionary/credential>:
>         "testimonials or certified documents showing that a person is
>         entitled to credit or has a right to exercise official power."
>         It's pretty hard for me to see how, under that definition,
>         credentials are not related to authorization. For me, it also
>         undercuts the assertion that credentials are all about
>         identity. I would say, rather, that they're all about trust in
>         the word of an issuer (about any topic, for any use case).
>         This is especially true when the spec already has a whole
>         section about bearer credentials, which by definition can't
>         establish identity.
>
>
>     I don't think I said that credentials implied anything about
>     identity.  It's the VC use cases and examples that I frequently
>     see that are mostly about identity.
>
>     Most people I've worked with who are just learning about ocaps
>     want to include some form of identity, role, or attribute
>     authentication.  I'm afraid that all those identity-based VC
>     examples will lead them down the wrong path.
>
>             All of the above.  I think a comparison of the VC and
>             zcap-ld specs answers the first and second points.  The
>             recent discussion about VP and VR is a hint that the VC
>             spec may become even more heavyweight than it is now.
>
>
>         The VC spec is not in flux. I don't see how it can get heavier
>         unless a new version is released. And I thought my examples
>         showed how it can be used in a way that's just as lightweight
>         as zCAP proposes to make an alternative mechanism.
>
>
>     Yes, you did show that.  The problem is that a lot of other fields
>     could be included in a zcap when they shouldn't be, and I'm afraid
>     less knowledgeable people will include them.  I would feel much
>     better about using VCs for zcaps if the spec limited which fields
>     are allowed in a zcap.
>
>                     First, an ocap is not a triple. An ocap is an
>                     unforgeable, transferable permission to use the
>                     thing it designates.  To me that looks like
>                     predicate/object with no subject.  (I guess you
>                     could call it subject/predicate with no object if
>                     you prefer.)  Using a verb "activate" in place of
>                     an noun "object" is strange indeed.  More
>                     importantly, I'm afraid people will create ocaps like
>
>
>         The question isn't about the definition of an OCAP (I agree
>         with yours). The question is whether the semantic content of
>         an OCAP can be represented with a triple. I say yes. Sorry my
>         example was confusing. The object in the sample triple was not
>         the verb "activate" -- it was a privilege (a noun) named
>         "activate self-defense mode". If I use a different privilege
>         name (e.g., "maintenance" -- the bearer has a maintenance
>         privilege), does that make it clearer? I am saying that the
>         subject of an authorization triple is the resource, the object
>         is the privilege, and the predicate is the association that
>         obtains between the two, for whoever the bearer happens to be.
>
>
>     Just because you can, doesn't mean you should.  There are only two
>     parts to an ocap, the thing (noun) and the permissions (verbs). 
>     Forcing them into a triple may confuse people.
>
>     I have one other concern about using VCs for zcaps.  How do you do
>     chained, subscope delegation?
>
>     --------------
>     Alan Karp
>

Received on Thursday, 24 December 2020 11:34:34 UTC