Can we turn opaque_info into more concrete fields, in the Voucher?

[geonnave]

The idea here is the same as in #23.

Proposal

Update Voucher so that instead of carrying opaque_info, it looks like this:

plaintext of Voucher = (
  role-of-v:        uint,  / choice(access-provider=1, owner=2) /
  directives-for-u: bstr,  / application-specific, e.g. frequencies, operation mode, etc /
)

Comments:

• the field role-of-v tells U whether V should be considered an owner/administrator, or simply a connectivity provider. This is more or less equivalent to the "assertion" item in BRSKI's Voucher, with the difference that no claim is made about "how to verify the ownership of V upon U". Another reason that motivated me in considering this field was a discussion I had with @chrysn about the "admin status of V".
• directives-for-u should contain any information that W may find useful to transmit to U. In a way, this is still equivalent to opaque_data, but just with a name that conveys the intention of the field.

Questions:

• does role-of-v make sense? are there other roles that should be considered?
• is there anything else that is missing? is there other type of information that should / could be sent in the Voucher, that would not be covered by the suggested fields?

[geonnave]

Logging some updates here.

1. Specifying the fields role-of-v and directives-for-u

During a design team meeting on April 11, we discussed that the two items discussed above could be specified in an appendix (therefore keeping OPAQUE_INFO as part of the Voucher).

The concern here is making the protocol too closed, while we are still not sure of all potential use cases and needs.

Just as a quick note, to me this starts to resemble a bit the case of EAP, where the main protocol is specified in a higher level, and then certain details are defined in later specifications. It differs from EAP as the authentication is defined (it relies on EDHOC's), but is similar to EAP as the underlying transport is not defined. Might bring this discussion into a separate issue.

2. directives-for-u: use case with LoRaWAN

The Join-accept message defined in LoRaWAN v1.1 ¹ is sent as a response to a successful Join-request. Join-accept contains the following fields: JoinNonce, Home_NetID, DevAddr, DownLinkSettings, RxDelay, ChannelFrequencyList.

Thus, when using lake-authz with LoRaWAN, the directives-for-u field could contain the fields of a Join-accept message.

¹ https://resources.lora-alliance.org/technical-specifications/lorawan-specification-v1-1