Re: VCs - zCaps / OCap a Discussion

@Daniel Hardman <daniel.hardman@evernym.com> I wonder if we're talking past
each other and putting @Alan Karp <alanhkarp@gmail.com> in a difficult
position of responding to the two of us separately 20 minutes apart.

I'm concerned about a very common, frequently, and heavily discussed
enterprise use-case where we must consider two legitimate interests around
authorization:

   - the ability for the requesting party (RQ) to delegate to another RQ
   with or without sub-scoping their authorization, and
   - the legitimate need of the resource server (RS) to consider the
   credentials of the client (RC) when enforcing the authorization

@Alan's reply to me
https://lists.w3.org/Archives/Public/public-credentials/2020Dec/0196.html
tries to address this issue by introducing the phrase "illegitimate
deleagtion" into our conversation. He seems to do this in order to address
the "legitimate" concern of the real-world resource server, just above.

This issue is handled by the GNAP protocol because it keeps the identity of
the client (RC) separate from the identity of the requesting parties (RS-1,
RS-2) in the delegation chain. It's this last delegation from some RQ to
the RC that presents the capability to the RS that we need clarity
on. @Alan talks about "improper delegation" and the risks of passing any
identity information to the RS. I get that.

@Daniel, please consider that we're talking about the real world where the
RS enterprise has constraints on the claims of the RC that are _separate_
from any claims or identity of whatever RQ interacted with the AS to get an
authorization capability.

The AS has a primary interest in keeping the RQ that they interact with
accountable. The RS has a primary interest in being compliant with RC
legitimacy.
The AS has no control over the RC that will eventually access the resource.
The RS has no legitimate interest in the credentials of the RQ.

Can we please merge these two discussions (how the authorization is coded
as a VC and how we deal with delegation deemed "improper" by the RS) into
one?

- Adrian

On Wed, Dec 23, 2020 at 9:36 PM Daniel Hardman <daniel.hardman@evernym.com>
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: {"id": "
> *url_identifying_the_resource*", "ocap": ["*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.
>
>
> 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> wrote:
>
>> Daniel Hardman <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
>>
>>>