search

decentralized-identity / confidential-storage

Confidential Storage Specification and Implementation
https://identity.foundation/confidential-storage/
Apache License 2.0
79 stars 23 forks source link

Debate: a goal of SDS should be that it can immediately be used for universal PWA storage #57

Closed csuwildcat closed 1 year ago

csuwildcat commented 4 years ago

It is my contention that the following should be a success condition of our work: the SDS spec defines the minimum features and components required for all SDS implementations to be so unified and interoperable, by default, that the following pseudo code could immediately be turned into a set of standardized DOM APIs:

var didDoc = await navigator.did.resolve(ALICE_DID_URI);
var datastoreEndpoints = didDoc.services && didDoc.services.filter(service => service.type === 'W3CStandardAppDatastore');
if (datastoreEndpoints && datastoreEndpoints.length) {
  try {
    var datastore = new Datastore(datastoreEndpoints);
    await datastore.connect();
    await datastore.create( { /* Alice adds something to her grocery list */ } )
    console.log(`
      Yay! You just wrote a new object entry to one of Alice's 3 datastore instances,
      and now they are replicating that object among them, without you, the dev,
      having to give even a fraction of a s*** about who/where Alice has chosen
      to host them, or what the hell they just did to sync the object. Hurrah, we just
      decentralized web apps and gave devs *real* serverless - how badass is that, folks?
    `)
  }
  catch (e) {
    // handle error if you can't connect to a datastore instance 
    // or writing a new object to a connected instance fails
  }
}

^ is this not our goal? My assertion is that it should be - what say you?

OR13 commented 4 years ago

{ /* Alice adds something to her grocery list */ }.... assuming that the structure is an object... and that data from the vault is processed after its decrypted.

OR13 commented 4 years ago

@csuwildcat maybe show how the data is consumed on the other end as well?

OR13 commented 4 years ago

For example, here is an eventstore interface on orbit: https://github.com/orbitdb/orbit-db-eventstore.

agropper commented 4 years ago

I don't understand the jargon enough to comment. What's PWA? What does a grocery list have to do with DIDs or VCs?

OR13 commented 4 years ago

Is this a feature request for a DOM api for SDS?

Needs additional comments on the higher level APIs.

OR13 commented 4 years ago

Is the use case for this developer convenience?

EvanTedesco commented 4 years ago

I don't understand the jargon enough to comment. What's PWA? What does a grocery list have to do with DIDs or VCs?

PWA is progressive web app I am assuming, and the grocery list was likely a contrived example.

That said I think the confusion suggests that more detail on this issue would be helpful. Would you say the use case you had in mind was something to the effect of:

"As a developer hoping to utilize SDS instance(s), I should have access to a set of standardized DOM APIs"

Acceptance Criteria: 1) Support for Progressive web applications 2) Given a set of service endpoints, a service object can be created to provide an interface to the associated SDS's.

As Orie suggested we would need more detail on the higher level APIs but I could see that discussion becoming its own issue should we decide to move forward with this issue.

EvanTedesco commented 4 years ago

Also I think this post by Daniel(Issue #60) helps to add color to this issue. It seems like it could have been intended to be posted to this issue in response to Adrian's question about PWAs.

"@agropper PWA = Progressive Web App, which represents the W3C international standards around locally installable, offline capable web apps. Your app must have an App Manifest (https://www.w3.org/TR/appmanifest/), which allows the browser to natively install a web app on your local machine. The app then has access to Service Workers (https://www.w3.org/TR/service-workers/) which allow for robust offline use, http wire intercepts for your app's requests to serve from local cache, etc. You can install PWAs today if you use Chrome, Edge, or Firefox on most platforms. Many sites are already taking advantage of this, so do check it out.

The goal of the Secure Data Storage work should be to create a robust, universal, replicated datastore that can back a new standard, native Web API that PWA authors can use to achieve a truly serverless app model. In this model, an app dev does not need to know where the user's personal datastore resides at all, they just need to request permission to write data to a subset of it. This allows for apps that have no backend (from a developer's perspective), which is basically the ultimate holy grail for all web devs who have ever lived, as well as a truly scalable model for doing serious decentralized applications (dapps)."

agropper commented 4 years ago

I suggest we continue this discussion on #60 and close this issue.

msporny commented 4 years ago

My concern is that this is too far reaching of a statement. The thing that gives us the original issue code is a WebIDL interface (polyfill or browser), none of the stuff below it. That said, we can probably translate this into a couple of goals:

That may be all that comes out of this requirement?

OR13 commented 4 years ago

@csuwildcat to consolidate the Hub interfaces and close this issue.

dlongley commented 4 years ago

There are a number of ways we could meet the goals set out in the OP without adding more browser APIs that are specifically for SDS. For example, note that the code snippet involves this line:

var didDoc = await navigator.did.resolve(ALICE_DID_URI);

In this example, ALICE_DID_URI is known a priori. So the question becomes, how would the site actually get this information? Which leads one to ask: could it ask for other information at the same time?

In that light, another option for meeting the goal in this thread could be that the PWA uses CHAPI to request a VP that includes one or more capabilities to access one of the user's vaults/hubs. The request could include whatever "filters" the requesting site desires. Then the user would use a digital wallet of their choice to complete the request and supply this information, along with an authentication proof for a DID of their choice in the VP.

The receiving site could then use user-space EDV/Hub client libraries combined with the given capabilities to access storage as the Web app needs.

The above, I believe, would meet the need for "universal PWA storage" -- and it could be done using many of the various other pieces the community has been working on without requiring new SDS-specific browser APIs. This approach can also provide a number of additional privacy benefits ... and it can be put together today with existing polyfills without a need to modify browsers.

agropper commented 4 years ago

Please help me understand the relationship between a DID, a biometric-secured app, and SDS.

1 - May I stipulate a standards-based alternative app equivalent to my 1Password linked to my biometric (face or fingerprint) on my three separate devices (iPhone, iPad, MacBook Pro)? For the purpose of this thread, can I call this a BSRW (Biometrically Secured, Redundant, Wallet) from Apple or 1Password or some other vendor of my choice.

2 - The BSRW app can have a security certificate of its own as we have with FIDO and some Apple extensions of FIDO. This allows relying parties to decide if to trust my user agent for their particular use-case.

3 - Let the BSRW be capable of issuing and managing Peer DIDs for all of the 200 or so service relationships in my current 1Password file. As with 1Password, I expect reliable storage and synchronization across my three equipotent BSRW host devices. For as many of the 200 service providers in my BSRW, I expect to store a did:peer or maybe just a did:key. Let's call this BSRW storage. It should be less than 20MB. (My current 1Password storage is less than 5 MB and I'm assuming a 4X expansion for DID documents). At current iCloud prices, 20 MB is worth about $3 / year which is on par with what I'm willing to pay 1Password for their BSRW update and support. In other words, a trusted, DID-standard BSRW across my three devices is worth $5-10/year.

4 - As I use my BSRW with various service providers, I would like to store various signed documents and transaction receipts for audit and legal purposes in case of dispute.

5 - Some services that I access through my BSRW are storage-intensive. For example, my total online-accessible hosted storage is around 20 GB. Most of it is subject to authorization for access.

So, 3, 4, and 5 above are three separate candidates for SDS. It's unclear to me which of them are a priority for our WG and what any of this has to do with PWAs.

On Wed, Aug 5, 2020 at 4:19 PM Dave Longley notifications@github.com wrote:

There are a number of ways we could meet the goals set out in the OP without adding more browser APIs that are specifically for SDS. For example, note that the code snippet involves this line:

var didDoc = await navigator.did.resolve(ALICE_DID_URI);

In this example, ALICE_DID_URI is known a priori. So the question becomes, how would the site actually get this information? Which leads one to ask: could it ask for other information at the same time?

In that light, another option for meeting the goal in this thread could be that the PWA uses CHAPI to request a VP that includes one or more capabilities to access one of the user's vaults/hubs. The request could include whatever "filters" the requesting site desires. Then the user would use a digital wallet of their choice to complete the request and supply this information, along with an authentication proof for a DID of their choice in the VP.

The receiving site could then use user-space EDV/Hub client libraries combined with the given capabilities to access storage as the Web app needs.

The above, I believe, would meet the need for "universal PWA storage" -- and it could be done using many of the various other pieces the community has been working on without requiring new SDS-specific browser APIs. This approach can also provide a number of additional privacy benefits ... and it can be put together today with existing polyfills without a need to modify browsers.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/decentralized-identity/secure-data-store/issues/57#issuecomment-669481230, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YIAXFBOG7MMXHWUYU3R7G5EXANCNFSM4NO3YTCA .

OR13 commented 4 years ago

@agropper you are touching on 2 things.

  1. Authentication to storage provider

Solutions include: OIDC, WebAuthN, Biometric support of Android and iOS... etc...

All of these imply a "registration" phase, where the perspective user is asked to review the ToS and PP of the provider, and IF they accept, to use some of the mechanisms I mentioned first, to register key material / other magic authentication bits for the purposes of authentication.

When the user's session with the storage provider expires (as it should regularly)... the user is asked to reauthenticate... in which case they prove they control the authentication factors they registered initially....

  1. Progressive web applications rely on storage providers

Commonly these are APIs (1Password / LastPass / EDV / Hub).... when you are on a website, and you choose to "prefill a password" or other allow a chrome / firefox extension to interact with the web page you are on... this is what is happening in the background:

  1. The extension checks to see if there is a logged in user, and if there is not, prompts you to log in if you want to interact with the web page.
  2. The extension has used its authentication context (session) to request all data, and then on the client, finds the passwords that are releveant to the web page you are on, and offers you the ability to prefill

IF we had native browser APIs for Hubs / Edvs.... this is how that picture would change...

The password manager would still be a browser extension.... but.... it would use browser APIs to connect to your data, not proprietary REST / web socket APIs.... it would pull your password data from your hub, using those browser APIs (which would ask for you to authenticate / authorize before proceeding).... and then the rest of the story would be the same....

In other words, we have vendor-lock in and non interoperability for password managers today, but they could all be built on encrypted data vaults / hubs... assuming we can define their interfaces sufficiently for developers to use them as building blocks for password managers.

agropper commented 4 years ago

Ok - so we're doing the use-case where the BSRW is a PWA. inline...

On Fri, Aug 7, 2020 at 12:11 PM Orie Steele notifications@github.com wrote:

@agropper https://github.com/agropper you are touching on 2 things.

  1. Authentication to storage provider

Solutions include: OIDC, WebAuthN, Biometric support of Android and iOS... etc...

All of these imply a "registration" phase, where the perspective user is asked to review the ToS and PP of the provider, and IF they accept, to use some of the mechanisms I mentioned first, to register key material / other magic authentication bits for the purposes of authentication.

When the user's session with the storage provider expires (as it should regularly)... the user is asked to reauthenticate... in which case they prove the control the authentication factors they registered initially....

  • Something you have: RSA Token
  • Something you know: password
  • Something you can do: sign / prove with previously registered keys.... WebAuthN / Yubikey...

  • Something you are: Irises / Fingerprints (but really this is used to register the stuff above... usually...)

    1. Progressive web applications rely on storage providers

My storage provider for 1Password is Dropbox. Indeed, my registration into Dropbox preceded 1Password.

Even if the Dropbox registration API were standards-based, bearing a SDS-certified logo, then I could use the same client, PWA, user-agent, to register with Dropbox knowing that Dropbox will also be the storage resource for the future BSRW. There's a bit of a circular issue here but if the future BSRW is storing the credentials in a standardized way and they are backed up, then I can see it. In real life, my backup to the 1Password credentials file in Dropbox is on paper or a password-protected PDF in human-readable form as the "standard". Now if I could only remember where I hid it.

Commonly these are APIs (1Password / LastPass / EDV / Hub).... when you are on a website, and you choose to "prefill a password" or other allow a chrome / firefox extension to interact with the web page you are on... this is what is happening in the background:

  1. The extension checks to see if there is a logged in user, and if there is not, prompts you to log in if you want to interact with the web page.
  2. The extension has used its authentication context (session) to request all data, and then on the client, finds the passwords that are releveant to the web page you are on, and offers you the ability to prefill

IF we had native browser APIs for Hubs / Edvs.... this is how that picture would change...

The password manager would still be a browser extension.... but.... it would use browser APIs to connect to your data, not proprietary REST / web socket APIs.... it would pull your password data from your hub, using those browser APIs (which would ask for you to authenticate / authorize before proceeding).... and then the rest of the story would be the same....

In other words, we have vendor-lock in and non interoperability for password managers today, but they could all be built on encrypted data vaults / hubs... assuming we can define their interfaces sufficiently for developers to use them as building blocks for password managers.

Sure, but there's little added value over Dropbox in this solution because the BSRW, 1Password in my case, is only dealing with storage category #3 (credentials). Being able to swap out 1Password for another BSRW is nice but it only happens every five years.

The real issue for SDS and PWA are BSRW categories #4 (receipts) and #5 (documents associated with the service providers under control of my BSRW).

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/decentralized-identity/secure-data-store/issues/57#issuecomment-670593262, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YPRHTUYPHRDWK55NETR7QRTRANCNFSM4NO3YTCA .

OR13 commented 4 years ago

@agropper I think you hit the nail on the head with the last sentence, I want to restate it the way I see it, and the way I believe @csuwildcat sees it.

What if websites could request access to sensitive user data, and the user could choose to disclose that data, and that data was not just credentials (what password managers an handle today)....

In order to achieve that... the website providers would need a standard interface for asking database like questions, and the user would need an interface for authorizing database responses... This is very similar to how indexdb or localstorage work today.... except the user doesn't control that data... the web origin does.... when an XSS happens, the attacker dumps all localstorage for every user... and they don't get a "consent to transfer sensitive stuff" prompt.

In the future... when an XSS happens, the attacker asks for data from "hub storage", the user gets notified that a website wants "all of their data"... and they say no... and nothing gets transfered.... if the user configured some secuity policy to grant all requests for all data to third party websites.... thats still on them... but the key point here, is that there should be a standard interface for users to allow their data (not just their passwords) to be requested by websites... and thats what this browser native hub sdk... is all about.