Suggestion: focus on sharing via link rather than via a messaging app

[bslassey]

When discussing with @nicksha we made the observation that the real goal that folks have in mind is the ability to share credentials with link (which can then be sent via a messaging application). By framing this as specifying the ability to send a key via a messaging application, we invite a lot of questions around why we're using a helper server and a link rather than the messaging services ability to transmit arbitrary blobs of data.

[dimmyvi]

That's a very precise observation. I think the main idea behind separation of the share link and credential data is two-fold - 1) We wanted to be able to use variety of regular comms channels to pass the link between sender and receiver devices - for simpler user experience 2) Wanted to separate sensitive data - encrypted provisioning info (temporarily stored on intermediate server) and secret that can be passed along with shareURL that allows to decrypt the data. Plus we wanted to avoid additional preliminary secure channel establishment between sender and receiver devices that would be required in case of pure messaging protocols (e.g. Signal or WhatsApp)

[nicksha]

I think @bslassey's suggestion here is to frame our goal as the ability to share credentials via link rather than sharing credentials over any messaging application.

With sharing via link, it clarify the mental model of how this credential sharing works, and it's implicit that any messaging channel can be used. This may help persuade those caught up in wanting to send data blobs over messaging services as to the simplicity of sharing via a link.

[dimmyvi]

Got it, thanks Nick. I will try to frame this idea into text in the draft

[dimmyvi]

Updated https://github.com/dimmyvi/tigress-requirements/pull/10 with this.

[alexpell00]

@bslassey I think sharing a url is our goal with our existing draft in mind, but I think that requirement is a bit specific for these general requirements. There could be a valid solution that is file extension based (i.e. a new .invite mime type) instead of url based. I agree that a url based solution is best, but I think we should describe why a url based solution is needed with abstract requirements.

[bslassey]

@bslassey I think sharing a url is our goal with our existing draft in mind, but I think that requirement is a bit specific for these general requirements. There could be a valid solution that is file extension based (i.e. a new .invite mime type) instead of url based. I agree that a url based solution is best, but I think we should describe why a url based solution is needed with abstract requirements.

I agree that sending binary data is an entirely plausible solution that has some nice benefits. However, I read these requirements as having selected the url-based approach and elevating some side benefits of that approach to requirements to necessitate that being the only viable solution. For example:

(Req-SmoothUX) Solution SHALL allow for user experience where neither Sender nor Receiver is presented with
raw data required only by the secure transfer protocol. The data SHOULD only be parsed programmatically and
not required to be presented to the end user. This data SHOULD never be visible to said user in whichever
messaging application the sender chose to initiate the transfer on. This eliminates the possibility of
merely sending the requisite data inline, through an SMS or email for example, rather than leveraging an
intermediary server.

This requirement seems to rule out anything besides a url-based solution. If this is the direction we want to go, then we should be clear about the intentions. If we are open to other solutions then we should scope these requirements to things that really are required and perhaps have a separate discussion of nice-to-haves.

[alexpell00]

I agree that the "(Req-SmoothUX)" requirement, and others, probably rule out anything other than a url-based solution. But I don't think that because other requirements force this design it is in its own right a requirement. Similarly, "(Req-Connectivity)" probably necessitates an intermediary server, but that doesn't mean we should have a requirement for an intermediary server.

Or, do you think we should include "derived requirements" maybe in a new sub section?

[bslassey]

I think "we should be able to have a smooth UX" is an entirely unobjectionable notion, but as it pertains to requirements its very subjective and can't be defined in such a way that offers an indisputable yes or no answer. As such, I think it is more of a consideration or evaluation criteria we may want to document and not a requirement.

Getting beyond the initial notion of Solution SHALL allow for user experience you can see that the additional details in the requirement have nothing to do with the protocol. For example, I could write a messaging app that fetches the raw data from the URL and presents that to the user. Conversely if we sent the data in binary form I could (and would presumably) present UX to the user about accepting a key and never show them the raw data. IMO these are entirely decisions for messaging apps to make that have very little to do with the underlying protocol and thus don't belong in this document.

All that said, this is probably a discussion better had in issue #7. My suggestion here is that if the authors are actually very committed to the URL approach, we should say that rather than work backwards from that and right the requirements to fit it.

[tfpauly]

I agree that the UX requirement is very hard to understand as a real requirement, and should not be in the formal list. It can be a guiding principle mentioned in text, but isn't about the actual protocol.

[dimmyvi]

I think that the intend is to present TIGRESS not as just a protocol, but rather "a combination of communication protocol, defined roles and relations between actors, recommendations to implementors, security rules and guidelines." If we define it so, then UI and UX become valid requirements, don't you think so?

[tfpauly]

No, I don't think that the UX (or the cross-platform, since every standard protocol must be cross-platform) aspects are protocol requirements. The point of this requirements list is to help people figure out what the right shape of the protocol is. Having a good UX is up to apps or OSes to deal with. Saying that an app or OS needs to recognize this as a particular content/message type so it can choose the right thing to display would be a better requirement.

[alexpell00]

I think "we should be able to have a smooth UX" is an entirely unobjectionable notion, but as it pertains to requirements its very subjective and can't be defined in such a way that offers an indisputable yes or no answer.

I agree with this. We can work on rewriting the wording so that it isn't objective. Or we could just remove it.

---

Can we have a requirement as prescriptive as to say that the solution must use a URL for the invitations? I thought we would need to come up with requirements that described the capabilities that we want, and a URL invite would then meet those required capabilities.

[bslassey]

Can we have a requirement as prescriptive as to say that the solution must use a URL for the invitations? I thought we would need to come up with requirements that described the capabilities that we want, and a URL invite would then meet those required capabilities.

I would very much encourage you not to try to write the requirements such that they preclude all other solutions other than a URL-based solution. If your end goal is to have a URL-based solution, then just go ahead and say that and let's have that debate. And that was why I originally filed this issue, to tease out if the authors were trying to preclude all non-URL based solution in these requirements.

My prefered approach would be to narrow the requirements down to just the requirements and leave the solution space as open as possible.

[alexpell00]

I would very much encourage you not to try to write the requirements such that they preclude all other solutions other than a URL-based solution. If your end goal is to have a URL-based solution, then just go ahead and say that and let's have that debate. And that was why I originally filed this issue, to tease out if the authors were trying to preclude all non-URL based solution in these requirements.

I think it is important that the authors, me included, are open to other solutions and changes to the draft we originally submitted. I feel like that is the whole point of the working group. We believe that a url invite is the best option, but if there is something else better that we haven't considered that would be worth considering. I worry that if we start defining requirements like "url invite" we will accidentally preclude good ideas that we hadn't thought of.

My prefered approach would be to narrow the requirements down to just the requirements and leave the solution space as open as possible.

I think we are saying the same thing, but we've done this in a confusing way with some of our requirements.

I think we should delete the smooth UX requirement and rely on this existing requirement:

(Req-RedemptionHandling) Shared Provisioning Information SHOULD route Receiver to redeem Provisioning Information using the designated Credential Management Application (e.g. Wallet).

What we really want is an invitation type that is routable to a specific application or service (i.e. when a user taps a link in a chat app another app or website is opened). Which we can do with a url or a new mime type.

[dimmyvi]

Ok, agree on removing requirement about URL-link