Self-Sovereign Identity Model Principles: Identifier and Identity Data Usage Licensing

[mwherman2000]

[This is a follow-up to the conversation that started here: https://github.com/solid/specification/issues/217#issuecomment-761859764. Check there for the initial details.]

Context

For example, to fully realize the SSI model in Solid, I not only want to specify access controls but also usage controls (in terms of usage license controls) whereby the consuming app needs to agree to example terms like:

App X can refer to but can not read and persist my content to any external storage system (beyond where the original content currently resides) without my expressed permission. App X cannot attach it's own ancillary information to my Identity (e.g. WebId) without my expressed permission. App X can read my content but cannot aggregate it (anonymously or not) to create its own new content without my permission. etc.

Questions

Is it envisioned that Solid will support these sorts of usage license terms ...as part of an end-to-end lifecycle? Is this type of support weeks, months, or years away? Is it on the roadmap?

Is there anything that needs to be changed in the current Solid architecture to support usage license terms? ...or has Solid been architected to make usage license terms a relatively straight forward design/implementation detail?

Best regards, Michael Herman Self-Sovereign Blockchain Architect Trusted Digital Web Project Hyperonomy Digital Identity Lab Parallelspace Corporation

[bblfish]

There was work done on this at the MIT Distributed Information Group by @oshanis (see her papers). It is quite clear technically how this can be done, namely link to a policy file in the HTTP header. This can already be done with Creative Commons Licensing. It would also allow the server to make claims regarding GDPR. But those things involve legal standards beyond the work done for CC.

[mwherman2000]

Selected comments from @elf-pavlik's reply plus my additional thoughts:

Would you see such application terms of service appropriate to present there to the user so that they can decide if they will authorize that application to access data on their behalf or not?

This is completely backwards relative to the Self-Sovereign Identity Model because it is the app asserting this own ToS and the user is left with today's "take or leave it" decision. Ultimately this discussion will migrate to how much of the SSI Model challenge is the Solid project willing to step up to.

I think in practice, app would have some terms of service and user would accept them and use the app or not and don't give it any authorization.

Ditto. See above.

I can't clearly see app agreeing to since piece of software doesn't seem fit to make choices like that or have any liability based on those choices.

This is new ground but Solid is also a relatively green field platform. Other projects have been working on this piece-meal from an individual technology perspective. Solid has a huge opportunity here being a focal point where all of these technologies can or are coming together.

There clearly needs to be some sort of automated negotiation of an SSI usage license (i.e. a contract) between the user and the app ...driven from the user perspective. This is at the very heart of the SSI model.

Service agreement seems to me something that would be made between application user and application provider, unless user uses self hosted application which I would encourage in solid and work on ecosystem making it as easy as possible.

Yes, made between application user and application provider but the terms and process must be driven by and controlled by the application user.

Let me get back to you about how the terms of a a user's SSI usage license might be specified and negotiated.

[mwherman2000]

Further, I think the overall SSI usage license negotiation process (story?) might looks something like:

1. User personally declares their SSI usage terms (claims?) based on their needs and the particular consuming app or service (Consumer)
2. User uses software to package their SSI usage terms into an SSI usage license (credential?) …possibly a Presentation of selected Claims from the User’s personal library of SSI usage claims (personal master SSI usage credential)
3. In lieu or in advance of a Consumer presenting their Terms of Service, User presents their SSI usage license credential for the Consumer to the Consumer
4. [perhaps some sort of semi-automated SSI usage terms negotiation takes place to arrive at an SSI usage contract (SSI usage contract credential) agreeable to both the User and Consumer.]
5. A Consent Receipt is sent to both parties along with the negotiated SSI usage contract

[elf-pavlik]

Would you see such application terms of service appropriate to present there to the user so that they can decide if they will authorize that application to access data on their behalf or not?

This is completely backwards relative to the Self-Sovereign Identity Model because it is the app asserting this own ToS and the user is left with today's "take or leave it" decision. Ultimately this discussion will migrate to how much of the SSI Model challenge is the Solid project willing to step up to.

I would just like to clarify that in solid ecosystem, none of the data (especially social graph) stays bound to any application. In other words preferably there should always be more than one choice of application that allows user to achieve any of their specific goals. There should never be a situation that choosing not to use specific application will prevent user from achieving their goal.

[mwherman2000]

I would just like to clarify that in solid ecosystem, none of the data (especially social graph) stays bound to any application.

I understand this ...that pod data stands by itself to be consumed by possibly multiple applications. But what is preventing an App Publisher from creating an app, that I grant Read permissions on some of my pod data, from reading the data and then writing it or otherwise persisting to some other storage? ...e.g. an App Publisher pod or non-pod storage

In other words preferably there should always be more than one choice of application that allows user to achieve any of their specific goals. There should never be a situation that choosing not to use specific application will prevent user from achieving their goal.

In any platform marketplace (Windows, Linux, Apple, any cloud platform, etc.), there is an illusion of having "choice" ...it's more often the case that each app category has one dominant app/service that most people feel compelled to use.

[bblfish]

@mwherman2000

I understand this ...that pod data stands by itself to be consumed by possibly multiple applications. But what is preventing an App Publisher from creating an app, that I grant Read permissions on some of my pod data, from reading the data and then writing it or otherwise persisting to some other storage?

There is no technical way to make this impossible, since information can always be copied.

But there are legal ways to do this, which can be supported technically by the server publishing metadata in the HTTP header linking to a machine readable license file. This has been explored by @oshanis when she was at the Distributed Information group at MIT (See link above to her papers).

Now in order to help enforce the license the server could add an access control rule that only makes the content available to clients that declare themselves (at the app WebID perhaps) to respect such licensing information. (This may be a new use case to propose to the access control group). This would make the app author responsible for informing the user of the licencing restrictions and keeping that data available.

[mwherman2000]

Now in order to help enforce the license the server could add an access control rule that only makes the content available to clients that declare themselves (at the app WebID perhaps) to respect such licensing information.

This starts to suggest an interesting layering where my concept of an SSI usage license (once negotiated and agreed upon) gets distilled down into a set of Solid access controls from the current architecture for the two parties involved (and subject content).

Something like...

Bob Consumer represents the App and/or App Publisher that consumes pod data from Alice User.

What is available in the broader digital ecosystem to support this type of process? …projects, draft/emerging standards, technologies, notations/schema?

[justinwb]

What is available in the broader digital ecosystem to support this type of process? …projects, draft/emerging standards, technologies, notations/schema?

@mwherman2000 While we're not specifically focused on license terms, mechanisms for reviewing access needs and communicating access grants between Agents / Applications in the ecosystem are covered in the Application Interoperability work being conducted by the Data Interoperability Panel. Additional terms could easily be included in those exchanges.

[mwherman2000]

I’ve finished what I believe is an interesting document describing an effective solution for the SSI Personal Data Usage Licensing (SSI-PDUL) problem and would appreciate your comments and feedback.

1. You can edit a Google Docs copy of my Word master version of the whitepaper here: https://docs.google.com/document/d/1yP0OgDhq-3TTIien5gsETi4jZdyiKbwE/edit

2. If you prefer to read a PDF version, you can download it from here: https://hyperonomy.com/2021/01/27/self-sovereign-identity-personal-data-usage-licensing-ssi-pdul-model-solution-concept-review-draft-0-27/

One, what I believe to be an authoritative, comment that I’ve received so far is: Otherwise, I think it's a pretty unstudied problem.

Abstract The purpose of this solution concept whitepaper is to provide the first complete description of the motivations, key concepts, problem statement, and solution approach for implementing the Self-Sovereign Identity Personal Data Usage Licensing (SSI-PDUL) Model, a functional component of the Self-Sovereign Identity Model (SSI Model).

This solution concept addresses the following user scenario:

How Alice User, an App User and Identity Owner, and Bob Developer, an App Developer and App Controller, might negotiate the use of Alice’s personal digital identifiers and any associated personal identity data by Bob’s app, based on Self-Sovereign Identity Model Usage Principles.

The scope of the Self-Sovereign Identity Personal Data Usage Licensing (SSI-PDUL) Model is personal digital identifiers and any associated identity data presented by Alice to the App. It does not include the permissioning of data internal to the App (although the natural extension of the solution to internal data is an obvious one).

The intended audience for this whitepaper is a broad range of professionals interested in furthering the application and use of the SSI Model in software apps, agents, and services using an SSI Personal Data Usage Licensing (SSI-PDUL) Model approach. This includes software architects, application developers, and user experience (UX) specialists; as well as people involved in a broad range of standards efforts related to decentralized identity, verified credentials, and secure storage.

The work documented here was performed under the auspices of the Trusted Digital Web project in the Hyperonomy Digital Identity Lab of Parallelspace Corporation.

Thank you, Michael

Best regards, Michael Herman Self-Sovereign Blockchain Architect Trusted Digital Web Hyperonomy Digital Identity Lab Parallelspace Corporation