Some requirements describe application best practices

[bslassey]

A few of the requirements specify application behavior or best practices that don't have any bearing on a protocol. Such as:

(Req-IntermediaryAttestation) An Intermediary SHALL implement mechanisms to prevent abuse by share initiating device, verifying that the device is in good standing and content generated by the sender device can be trusted by the Intermediary. The trust mechanism could be proprietary or publicly verifiable ( e.g. WebAuthN). (Req-ReceiverTrust) The Receiver device SHOULD be able to evaluate the trustworthiness of the Intermediary using a list of trusted/approved intermediaries. (Req-RedemptionHandling) Shared Provisioning Information SHOULD route Receiver to redeem Provisioning Information using the designated Credential Management Application (e.g. Wallet).

[dimmyvi]

We are trying to declare here trust relationship between Sender (share initiating device) and Relay (intermediary) server. It does not affect the protocol per se, but it affects the logical flow - who can start the flow, and what device can relay trust to create a mailbox. I believe this is important to this solution and we received multiple questions in IETF 114 to explain this.

[bslassey]

It sounds like this is just definitional: the party that starts the transaction is the sender.

As I understand it, we're also not taking the relay server as a given, so it shouldn't be in the requirements.

[castiz]

Is this issue good to close? The requirements related to the relay server are now in a section specifically for if an intermediary is required.

[bslassey]

Is this issue good to close? The requirements related to the relay server are now in a section specifically for if an intermediary is required.

No, that was just a separate formatting change. Best I can tell these requirements shouldn't be in the document as they are effectively saying "these are good ideas for the implementors to think about" (which, to be clear is helpful to include in a document defining a protocol) and not requirements that would impact the design of the protocol. As such I think we should either delete them. Or, if there is some requirement on the protocol that I'm not seeing we should tease that out.

[castiz]

Got it! Yes, we can work on this set of requirements. We also have an implementation guide now, so it might be worth adding pieces that don't make sense for requirements doc to be in the implementation guide.

[dimmyvi]

Although I agree with the statement that the Relay server should not be a given - and we potentially can remove (Req-IntermediaryAttestation) and (Req-ReceiverTrust) - since they are bound to this particular server, I still feel that (Req-RedemptionHandling) is important to have - if we want to direct the solution to handle provisioning information(passed b/w 2 devices) in an application that can recognize and use it for provisioning. I'm afraid that removing this requirement will require us to either 1) document the format of provisioning information (that will bring in scope a whole multitude of proprietary provisioning protocols) or 2) document the provisioning flow in a protocol, or both. Both will require us to bring into scope the provisioning path with exponential growth of complexity. We strongly feel that we want to decouple transfer of provisioning info from provisioning it to a new device, keeping only the transfer in scope - and reusing existing protocols (e.g. CCC) for provisioning - separately from Tigress.

[bslassey]

(Req-RedemptionHandling) is System and/or app behavior that has nothing to do with the protocol. I disagree that removing this will result in documenting the provisioning format or protocol and therefore I don't think this expands scope at all.

[alexpell00]

(Req-RedemptionHandling) is System and/or app behavior that has nothing to do with the protocol.

This requirement isn't necessarily around app behavior, but more saying that our protocol should allow this type of app behavior.

I think most of our requirements fall into a similar bucket. Requirements on the protocol to make it usable for the system / app. If we didn't have these types of technical usability requirements then we could use any established secure messaging protocol.

--

I agree our wording is off on these types of requirements, and that we have phased it like an app requirement. What do you think about something like:

Provisioning Information MUST be able to specify the applications or entities that should handle and facilitate its redemption with the Provisioning Partner.

This would be solvable in a litany of ways.

[dimmyvi]

this was addressed in a new requirements document with sample implementations was published on 17 Feb. We can close the issue