Can SSI avoid linking control with possession?

[vsnt]

Concern brought to CCG Leadership via Adrian Gropper. Details here: https://docs.google.com/document/d/1MaS6Qs6g_dom_Y66jCWrcck6KJozAS3JZU1aLU6j598/edit

[agropper]

Can we develop a shared understanding of what delegation entails in the VC / SSI context?

In the SSI context:

• A VC is a self-verifying document.
• Transfer of a VC across legal entities SHOULD be under the control of the Subject of the VC.
• We can separate control from processing in the sense of GDPR and Zero Trust Architecture.
• Communication of a VC from Server A to Client B SHOULD NOT be under the control of the server as a mere processor.
• The controller of a VC MAY be either the Subject or a delegate of the Subject.
• Client B is the responsibility of the entity that is receiving the VC, which may or may not be Subject of the VC.
• The controller or processor of a VC SHOULD trust the operator of Client B rather than the client itself.
• From a VC access protocol perspective, Client B could be a browser or app as the operator/user-agent.
• To gain VC access, Client B SHOULD present an authorization token to Server A.
• The protocol or process by which Client B received the authorization token SHOULD be under the control of the controller but subject to limitations or constraints imposed by Server A as processor.
• The protocol for receiving an authorization token MAY be a separate standard from the protocol for presenting the authorization token to Server A.

Pausing here to see if anyone objects to this framing of the issue.

[TallTed]

@agropper -- I do not see much "framing" here. Nor do I see a clear statement of "the issue".

Your bullets do not have any logical flow; they are not parallel (as they should be, in a single <ul> bullet list), nor do they build on/from each other (which would be quickly addressed by making this an <ol> numbered list). They appear to be a mix from of list items from different tiers and/or stages, and might make more sense if they were ordered and indented along such lines.

The Google doc (why was that content not simply posted to an issue or other thread, perhaps with each out-of-context quotation as its own comment on the thread -- or perhaps with each comment starting its own thread/issue?) only adds to the confusion.

I've picked one immediately problematic bullet to discuss in some depth below.

• Transfer of a VC across legal entities SHOULD be under the control of the Subject of the VC.

In today's world, including the sub-world of SSI, anyone can assert anything about anything.

All a VC does is allow the Asserter (the Issuer) to enable Verifiers (at any remove) to Verify that the Asserter/Issuer Asserted whatever Assertions are in the VC.

A VC Subject has no way to prevent an Issuer/Asserter from Asserting anything, nor to influence/limit the Holders or Verifiers to whom the VC is transferred.

A VC Issuer has no way to influence/limit the Holders or Verifiers to whom the VC is transferred, though the Issuer may have some control over the Verifiers it will answer (in the case of VCs which require such a pingback).

Now, you may be speaking about a special class of VCs and/or Subjects. You may be speaking about a particular arena in which the transfer of some document(s) -- VC or otherwise -- is restricted. In such case, you should qualify every instance of "VC" in your statements such that we readers can tell you're not speaking of the general case.

But you're not speaking about any general case, and you're not speaking about any special case that exists today.

You might be conflating DIDs with VCs. Some of the attributes you ascribe, but which do not apply, to VCs, do (or can) apply to DIDs... but this is not true of every aspect you raise, so I'm still confused.

It's not at all clear what you want to get out of this thread.

[agropper]

Hi Ted,

I'm using SHOULD whenever I mean for a normative test to exist, knowing that, as you point out, there will be exceptions.

Given that as a definition of SHOULD as it relates to testable protocols, I don't understand your objection. Are you looking for a set of points that would be based on MUST?

I listed the 11 bullets in order that would make the intent clear. If you disagree with the ordering, anyone should feel free to propose a different order. The order should not matter much given the normative intent in this issue.

On Mon, Jun 21, 2021 at 11:31 AM Ted Thibodeau Jr @.***> wrote:

@agropper https://github.com/agropper -- I do not see much "framing" here. Nor do I see a clear statement of "the issue".

Your bullets do not have any logical flow; they are not parallel (as they should be, in a single

bullet list), nor do they build on/from each other (which would be quickly addressed by making this an
numbered list). They appear to be a mix from of list items from different tiers and/or stages, and might make more sense if they were ordered and indented along such lines.

The Google doc (why was that content not simply posted to an issue or other thread, perhaps with each out-of-context quotation as its own comment on the thread -- or perhaps with each comment starting its own thread/issue?) only adds to the confusion.

I've picked one immediately problematic bullet to discuss in some depth below.

• Transfer of a VC across legal entities SHOULD be under the control of the Subject of the VC.

In today's world, including the sub-world of SSI, anyone can assert anything about anything.

All a VC does is allow the Asserter (the Issuer) to enable Verifiers (at any remove) to Verify that the Asserter/Issuer Asserted whatever Assertions are in the VC.

A VC Subject has no way to prevent an Issuer/Asserter from Asserting anything, nor to influence/limit the Holders or Verifiers to whom the VC is transferred.

A VC Issuer has no way to influence/limit the Holders or Verifiers to whom the VC is transferred, though the Issuer may have some control over the Verifiers it will answer (in the case of VCs which require such a pingback).

Now, you may be speaking about a special class of VCs and/or Subjects. You may be speaking about a particular arena in which the transfer of some document(s) -- VC or otherwise -- is restricted. In such case, you should qualify every instance of "VC" in your statements such that we readers can tell you're not speaking of the general case.

But you're not speaking about any general case, and you're not speaking about any special case that exists today.

You might be conflating DIDs with VCs. Some of the attributes you ascribe, but which do not apply, to VCs, do (or can) apply to DIDs... but this is not true of every aspect you raise, so I'm still confused.

It's not at all clear what you want to get out of this thread.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/community/issues/195#issuecomment-865128399, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YNVLORG5CED2XZZZADTT5LMNANCNFSM4657NBOA .

[TallTed]

A few more observations...

Can we develop a shared understanding of what delegation entails in the VC / SSI context?

"The VC / SSI context" is not a clear context, to begin with. It is an ill-/un-defined blend of VCs (a technological standard) and SSI (a philosophical approach to various technologies, many of which have not yet been specified).

Until that context is clearly defined, the answer to this question seems clearly to be, "No."

• A VC is a self-verifying document.

It is not clear to me what you think "a self-verifying document" is, but I'm fairly certain that VCs in general will not satisfy your definition.

• We can separate control from processing in the sense of GDPR and Zero Trust Architecture.

Can we? Maybe. SHOULD we? I think it likely you meant to say so, but you didn't, so your normative intent is again (still) unclear.

It is also unclear what you mean by both "control" and "processing". Again, I think I have an idea -- but that comes from other things you've said, not from this issue (including the Google doc alongside).

[agropper]

The shared SSI understanding was / is to give the subject maximum control over how VCs are processed by issuers and verifiers. Control through possession is just a subset.

On Tue, Jun 22, 2021 at 9:41 AM Ted Thibodeau Jr @.***> wrote:

A few more observations...

Can we develop a shared understanding of what delegation entails in the VC / SSI context?

"The VC / SSI context" is not a clear context, to begin with. It is an ill-/un-defined blend of VCs (a technological standard) and SSI (a philosophical approach to various technologies, many of which have not yet been specified).

Until that context is clearly defined, the answer to this question seems clearly to be, "No."

• A VC is a self-verifying document.

It is not clear to me what you think "a self-verifying document" is, but I'm fairly certain that VCs in general will not satisfy your definition.

• We can separate control from processing in the sense of GDPR and Zero Trust Architecture.

Can we? Maybe. SHOULD we? I think it likely you meant to say so, but you didn't, so your normative intent is again (still) unclear.

It is also unclear what you mean by both "control" and "processing". Again, I think I have an idea -- but that comes from other things you've said, not from this issue (including the Google doc alongside).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/community/issues/195#issuecomment-865994290, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YJLTSRSMMXK3QD6K7TTUCHIVANCNFSM4657NBOA .

[TallTed]

Again:

In today's world, including the sub-world of SSI, anyone can assert anything about anything.

All a VC does is allow the Asserter (the Issuer) to enable Verifiers (at any remove) to Verify that the Asserter/Issuer Asserted whatever Assertions are in the VC.

A VC Subject has no way to prevent an Issuer/Asserter from Asserting anything, nor to influence/limit the Holders or Verifiers to whom the VC is transferred.

A VC Issuer has no way to influence/limit the Holders or Verifiers to whom the VC is transferred, though the Issuer may have some control over the Verifiers it will answer (in the case of VCs which require such a pingback).

In other words: Subjects of VCs have no "control over how VCs are processed by issuers and verifiers", whether SSI is in play or not!

SSI is Self-Sovereign Identity. It means you can give yourself a cryptographically secure identifier without asking permission nor paying fealty to any other entity. That's all.

SSI doesn't (technically) enable you to stop any other entity from using that identifier to refer to you (or, though it might seem silly, to any other entity), nor to limit the statements that might be made about the referenced entity.

Some legal framework might convey that power to you, but this is entirely out-of-scope for all VC- or DID-related groups I know of, as well as all groups (VC, DID, or otherwise) within the W3C umbrella.

[agropper]

I had the opportunity to present this issue to the GNAP meeting at IETF 111. The 21 minute video is at https://www.youtube.com/watch?v=iVx8_DbO3rM&list=PLC86T-6ZTP5ik187oPfRrOUaMw1AuLLi6&t=491s

Although the title refers to VC-HTTP API, the presentation references four other W3C / DIF workgroups that could be impacted by a delegation-capable authorization protocol.

[vsnt]

Closing until there is sufficient interest to move forward. This can always be re-opened.