clarify the protocol, add cID in clear to the proof-of-key message about fusion-identity-spec HOT 7 OPEN

I like the message sequence chart very much, helps reading the protocol!

Thanks, I added it with a slight variation of the one you posted.

I suggest to add the consentID to the proof-of-key message in clear, not only implicitly in the signature, because one should close all invite transactions individually (I understood that there can be several of them running in parallel, e.g. issued by different members of a fusionID), visible for all to see this closing.

Yes it should be included. That is a good suggestion.

From that transaction point of view, the xID is its identifier. Hence, I suggest to replace all consentID values with xID, as I called the invite's message ID, and use the fieldname inviteID.

We have to be careful here, in the signature we can't replace consent with inviteID because that would leave us open to a replay attack, so for now I'd rather keep using consentID as that is unique.

Finally, in the consent section of the spec, one could spell out that this message format also permits to decline the invite which then also closes this transaction.

Good idea, I have improved that section now.

from fusion-identity-spec.

Thanks @arj03 for the kind uptake of my comments.

Regarding replay attack, I'm not sure to follow: the xID is unique and is targeted for one party only (@phone, and no one else can answer that invite). Because it is a self-contained transaction of two messages (in case of decline) or four (in case of consent), afterwards the transaction is closed and the xID can never be used again. Moreover, with append-only logs we don't need the protection against temporal attacks. Or do I miss something?

from fusion-identity-spec.

Oh, that was probably not very clear from the spec, but you can invite any number of people in a single messsage.

from fusion-identity-spec.

Ah yes, I did not read carefully "Invite one or more feeds to join a fusion", sorry about this.

Two questions there:

• is factoring out an invite message (for multiple invitees) worth the effort of having to keep track of two levels of transaction IDs? True that using xID requires (N-1) additional log entries for N new members, where N, the numbers of smart phones you want to include in a batch, is small: typically you would add one device at a time.
• And why is the invited field a dictionary, instead of a list?:

 {
    '@2Cu6gvifd39hHvE/HkT4M7dP5KY5CZ+AsYzM1w2mtT8=.ed25519': 1
  },

from fusion-identity-spec.

I think the main difference in our views is that you view each invitation as a transaction, while I view the state of the fusion as the main point of reference when looking at changes to see if they are valid or not. Notice we don't specify any time or even a close on an open invitation (by the sender). For each feed id they can be in only one group: outsider, invited, consented, members. This is also why the feeds are in a dictionary, as that makes it easy to add them together, lets say if someone was invited twice. I think this way of thinking works well for distributed systems where a peer can be offline for an extended period of time. In any case, any member can terminate the fusion (and start another) if for whatever reason (stale invite being used after a long time, lost device etc.) they decide that this is the best way forward.

from fusion-identity-spec.

Seems we are looking at it from different points of view: you from app space, me from networking land. With tinySSB in mind I tend to question every bit and the simpler the protocol the better. The dictionary approach has less empathy on my side as for example using a set (inside the app) would give you the same ease of "adding together" - the protocol should be agnostic to app-internal data structure choices. Regarding time we fully agree: it does not matter how long a transaction stays open. Just that I note that focusing on the closed state of a Tx makes sense as it's the terminal state (members cannot leave).

One comment of yours intrigued me: "I view the state of the fusion of the main point of reference". This hintes at a high-level view of the fusion abstraction and I would be curious to see how you model this (shared!) high-level abstraction, could also be helpful for the spec. The operations like invite etc are low-level mechanisms, not the methods on the abstraction, I would reckon. Now I'm hooked. This is my take:

type Shared_Addonly_Group {   // SAG
  constructor(keyPair,creatorPk)    // initiated by the first member
  constructor(fusionID,consentFlag) // react to an invite by creating your SAG replica
  addMember(pk) -> accept/reject // async, fails for nonmembers, idempotent
  getMembers() -> list           // works for everybody
  privateSend(data)              // works for everybody, implements reliable confidential group broadcast
  onNotify(data)                 // upcall, never called for nonmembers
  cancel()                       // fails for nonmembers, idempotent
  isCanceled() -> true/false     // true if tombstoned, works for everybody
}

something like this?

from fusion-identity-spec.

The dictionary approach has less empathy on my side as for example using a set (inside the app)

It started out as a list actually but was changed to the dictionary structure as that maps well to ssb-crut. I do agree that we should try and separate application concerns from the protocol.

something like this?

Yes this is very close to what I have. I think of it as a distributed state machine where each node much converge to the same state, but I guess thinking of it as a SAG replica could also make sense. ssb-crut already had a lot of the right pieces to model this. It has schema and works on tangles. I extended it to make it easier to model these kind of state constructs.

To answer directly to each method:

type Shared_Addonly_Group {   // SAG
  constructor(keyPair,creatorPk)    // initiated by the first member

This is create

  constructor(fusionID,consentFlag) // react to an invite by creating your SAG replica

I called this consent

  addMember(pk) -> accept/reject // async, fails for nonmembers, idempotent

I called this invite

  getMembers() -> list           // works for everybody

This is read. There is also methods like all and tombstoned that works on all fusions you are aware of.

  privateSend(data)              // works for everybody, implements reliable confidential group broadcast

Yep there is a special way to send these. Encryption is in the JS stack handled mostly in one place, but other than that it is the same idea.

  onNotify(data)                 // upcall, never called for nonmembers

I split this into 2 parts:

• actions based on state change, this could be consent -> send key
• the state machine, that takes a message and updates the state of the fusion if they are valid

  cancel()                       // fails for nonmembers, idempotent

This is tombstone

  isCanceled() -> true/false     // true if tombstoned, works for everybody

This is a part of read or the higher level tombstoned for all tombstoned fusion.

It is interesting that you called it Shared Addonly Group, in the private groups ngi group we talked about if it would make sense to try and decouple member management from key management. This reason being that member management could be used in other context. A fusion identity is a construct where the members are public, but you can still communicate privately with the group members. In a private group the members are private, and in order to communicate with the group, Ahau created a p.o box. You could also think of a group that was fully public (all messages and member states), that would be very similar to a fusion identity. Mix was quite keen on these concepts separate and it probably makes sense when we talk about box2 encryption, it just feels like there is a lot of the same concepts here. Another thing that is important for addonly groups is that the evolution of such a group (forking or removing a member) is what we call redirects and attestations. Those two concepts are also quite general. In tinyssb you have something similar (ssb:message/sha256/VhSjGE4713avLfYRSnrSH-WcASL7WMNFWnuxnDGMmWo=), do you have any input on that part, or do you consider those things separate?

from fusion-identity-spec.