DeRecMessage with GetSecretIdsVersionsRequestMessage has no secretId

[jorabin]

Need to note that in this case the field is omitted or empty

[jorabin]

To amplify: it should be possible to use this either as a recovering sharer or as a regular sharer. The hypothesis is that a recovering sharer creates a bogus secret then deletes it. However, if you are an active sharer with no secrets, it seems strange to have to do that.

[lbaird]

The secretID is the identifier for a communication channel, including the keys of the sharer. So it isn't bogus: it's a legit channel that will be used for recovery. It could also be used to share secrets in the future, though it doesn't have to be used for that. I think this issue can be closed.

[jorabin]

Now that we have the concept of a key id the structure looks like keyid<-secretid<-versions and I don't understand why we need to create a secret to find out about other secrets.

[lbaird]

The same public encryption key might be used for multiple secrets. A given person might even decide to have a single public encryption key shared across all other parties, secrets, and versions. So the keyId isn't a replacement for the secretId. We still need the secretId to identify the channel.

[jorabin]

fair enough, and there's no need for this to be discussed separately to the general discussion on Authentication Context