JD authentication via SetupConnection?

[plebhash]

SRI is starting to heavily depend on Open*MiningChannel.user_identity for authentication:

• RFC: hybrid solo/donation pool mode sv2-apps#288
• Enable SOLO mining mode on our Pool sv2-apps#135

this is however restricted to Mining Protocol, while all JDP messages still lack some kind of user_identity

edit: the sentence above is not true

AllocateMiningJobToken.user_identifier could play a similar role on JDP

[plebhash]

there's Sv2 industry players repurposing SetupConnection.device_id for KYB authentication under JDP

therefore, SetupConnection seems like a contender for enabling JDP authentication

I see two paths forward in this direction:

1. rename SetupConnection.device_id into SetupConnection.user_id
2. add a new SetupConnection.user_id alongside SetupConnection.device_id

both options have a major drawback however:

• SetupConnection exists for both MP and JDP
• Open*MiningChannel.user_identity will become redundant with SetupConnection.user_id

[GitGab19]

Why do we need to change the SetupConnection, when we already have the user_identifier in the AllocateMiningJobToken message?

[plebhash]

hmm that's true, I completely missed it!

@Fi3 have you considered this approach?

[plebhash]

cross referencing: stratum-mining/sv2-ui#73 (comment)

[Fi3]

I can change it. Honestly it was more like cause I already have it is implemented and well tested and don't want to change, also SetupConnection.device_id sounds a little bit strange since it imply a mining device sender but the SetupConnection message can come from anything mining device proxy even from a pool when it connect to the TP. I'm ok with leaving it like that and change dmnd implementation, is not somtething that I can do rn but we can defentively put it in the backlog.