PATCH: inform upper over layers which peer has accepted config

[Eliot Lear]

Thank you for your response Jouni.  Please see below:

On 27.11.22 08:16, Jouni Malinen wrote:
> On Tue, Aug 02, 2022 at 03:16:08PM +0200, Eliot Lear wrote:
>> This patch might require some discussion and some edits.  It is possible that two or more
>> devices might get configured at the same time.  In this case, the upper layers may wish > to the status of respective devices.  I have tested the dpp_tcp.c code.  I have NOT
>> unit tested the dpp_supplicant code (I don't have a test setup for that).
> This way of identifying a peer is problematic since there is no separate
> bootstrapping information entry for a peer when acting as a DPP
> Responder (well, ignoring the mutual authentication case here) since no
> QR Code (etc.) was actually read on the Responder device. As such, the
> upper layers would not really have any context for determining what the
> particular peer bootstrapping information identifier might be in such
> cases.

Forgive my confusion, but the code above what you quoted indicates that 
clearly we are providing a conf result, which means that we are the 
configurator and we have already authenticated the peer with the public 
key from the enrollee's qrcode. Am I misusing / misinterpreting the struct?

Eliot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20221128/c930e072/attachment.sig>