Re: VCs - zCaps / OCap a Discussion

I want to clarify one thing.  I used the term "illegitimate delegation" to
mean one that is not properly signed or that attempts to delegate more
permissions than the delegator has.

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


On Wed, Dec 23, 2020 at 8:50 PM Adrian Gropper <agropper@healthurl.com>
wrote:

> @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
>>>
>>>>