aries-rfcs
aries-rfcs copied to clipboard
hyperledger
RFC 434 - Service block priority
In the RFC it states the service block is:
an item that is the equivalent of the service block of a DIDDoc that the receiver is to use in responding to the message
In the DIDDoc spec (RFC 67), it mentions that priority is a mandatory field.
Shouldn't the examples within RFC 434 include priority in the service block?
Good catch -- thanks for raising that. @llorllale @dhh1128 @TelegramSam --- do we agree that RFC 434 needs to be updated vs. any change in RFC 67? The text for 434 implies priority order, so I think it's fairly obvious we should do that.
@swcurran
I would be OK with including priority if we also remove this loose requirement:
The sender MUST put the array into their order of preference,
And adjust this loose requirement accordingly:
the receiver SHOULD prefer the entries in order.
It seems this was never addressed. There are current implementations that don't include the priority field (e.g. ACA-Py), which means it's not compliant with RFC 0067.
What should be the result of this issue? Making priority required now (even though it theoretically was already required) may not work well with existing implementations. Per our discussion at the Aries WG we're already diverging from RFC 0067 by using did:key dids a recipient keys instead of actual key reference (#). Is this another thing where we diverge from RFC 0067? So instead of priority the priority is set defined by the order of the services in the array? That would make more sense to me as public dids in the services array can't contain a priority. Happy to make a PR if we can get to an agreement on how this should be resolved
May be worth to shortly discuss during the WG @TelegramSam
The wording on the priority field is terrible -- probably my writing. Is the priority item mandatory, or is it mandatory that if present, the value be an unsigned int, especially given the "default of 0" phrase. 🥺 If it must be there, there is no need for a default value.