Hello Daniel,
Firstly, thanks so much for attending our talk. I'll try to answer your questions to the best of my ability, and feel free to email me directly for further explanation.
> At about 18 minutes, Nick was talking about a pre-shared key flow for authorization. My question is, would that flow inherit the same problems as an encrypted export?
In the pre-shared key flow I mention, the modality of the key would be through a public/private key pair negotiated by the authorizing party, rather than a shared password. So, in a potential authorizing party flow, a key pair would be shared with both the importer and exporter that they could use to either encrypt the payload and/or prove that the authorizing party has authorized the exchange of the credentials.
>First, it seems this would only work for backup within a single provider, the exported backup couldn't be used with any other provider unless it was installed and able to enter into this bi-directional communication at the time of export.
First, not necessarily. One could potentially use a password or, more ideally, PKI, and then provide that decryption secret to the importing party, in the case that the importer and exporter are different providers. In the singular case, the provider could potentially hold the authorizing party export key.
> Second, even for local backup within the same program, where are the keys to decrypt the backup actually stored?
This is out of scope for the protocol and data format. Neither -and to use the working names here- CREEP (CREdential Exchange Protocol) nor CEF (Credential Exchange Format) should make any determinations about how the importer, exporter, or platform should store their keys, but we'll say that it should be secure.
>This again could just be my ignorance of how this all works, but where this bi-directional auth-flow is concerned, am I correct in understanding that (absent using the pre-shared key authorization flow) both programs would need to be installed simultaneously?
Not necessarily but I imagine that will be the most common scenario. One could imagine a case where an exporter, running in a browser extension, is capable of performing CREEP with an importer running via a web application.
>The talk mentioned the OS negotiating some of this communication -- I think I understand that but I want to make sure; does that cover discoverability and programs presenting as migration targets?
Yes.
> In other words, is the list of providers I can import from and export from something that has to be coded into each client, or is this a generic interface where Provider A goes to the OS and says, "the user wants to migrate, what can they migrate to" and the OS says "here's the list".
The latter
>My concern is whether a smaller or independently compiled provider will show up in that list if a larger provider like 1Password or Dashlane isn't aware that it exists. There's a concern (if this is working through pre-negotiated lists of providers) that this could end up being portability *only* for the largest providers and not for anybody else.
That is indeed a concern, but ideally when we look for valid importers on, for example, Android, we'll be filtering apps by interfaces rather than hard-coded IDs.
To your concerns around phishing and avoiding allow/block listing from occurring, you'll be glad to know I share them. I have some thoughts on how we can do this, and we'll have firmer updates later this year, but in the mean time I invite you to reach out if you want, and we should have a v1 draft of the two standards published shortly for public viewing.
Thanks,
NS