<div dir="ltr"><div class="gmail_default" style="font-size:small">I came across an interesting detail while implementing a PIN code based authentication scheme for the Mesh which I think indicates a much wider security concern.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Carl Ellison argued that we need to treat user interface 'Ceremony' as an intrinsic element of the protocol. My standards process experience is that is absolutely essential. Unless you model the user as part of the protocol, the user becomes a magic asterisk solving all the security concerns using information they haven't got.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So the specific question that comes up is this: Alice issues a PIN authentication code to allow connection of a device and hands it to Bob out of band. The PIN is used to authenticate a device. What should happen when it is then used to authenticate a second device before the code expires?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The traditional response to this is to essentially ignore the second connection attempt. Report it to the user as an error but thats pretty much it. Thinking the ceremony aspects through, I think that is the wrong approach. What should probably happen is to refuse the connection and place the previously connected device on hold.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">What I haven't managed to do yet is to work out how to generalize the approach. Perhaps it is as simple as 'error messages don't transfer responsibility back to the user'. By which I mean tell the user something happened but don't assume that is the end of the matter.</div></div>