(Doing this on the XMPP social list, for lack of a better home)

So I have started to experiment with the use of QR codes (2d barcodes)
as a way for XMPP-capable media centres to communicate their address
to nearby devices, eg. smartphones that might not be able to find them
via Bonjour/Rendevous, either because the mDNS stuff doesn't work on
all LAN configurations, or because they're on different networks. I'm
looking for some advice about how far to push things on the QR Code
front: might it make sense to include a hash of a cert in there?

Couple of mockup qr codes here -

http://www.flickr.com/photos/danbri/4358715185/
http://www.flickr.com/photos/danbri/4359291206/

 - these encode something like xmpp:[email protected]/tv12345,
where I am a bit vague on what that final token amounts to. It could
be a short term or single use id.

Dave asked about including a hash of the 'TV's cert could also be
squeezed into the qrcode. Possibly even at the expense of the retro
artwork currently included.

http://identi.ca/notice/22102395 @danbri I like the QR thing. Is there
space to include a hash of a cert there, too, for security? (Would
help with 174, too)
http://identi.ca/notice/22087629 @danbri Erm...
len(hashlib.sha512('').hexdigest()) == 128 aparently

Basic story is of communication between smartphones acting as remote
controls for networked mediacentres. Possibly acting as distinct JIDs
somehow linked to their human owners, or perhaps acting directly
through their owners XMPP accounts. At the moment I have been
prototyping on the loose assumption that each media centre gets its
own full  XMPP account, while perhaps the smartphones are logging onto
their owners' normal XMPP account. The XEP-0174 stuff
(http://xmpp.org/extensions/xep-0174.html) is relevant both for those
cases where it can be used for discovery, but also as a mechanism by
which a slow server-mediated communication might drop down to a local
link when both ends of the connection 'realise' they are in fact in
the same LAN.

So - if the qrcode could be used to pass not only an xmpp: address but
also a hash of its cert, how might that be useful? and how
truncated/lossy/risky a fingerprint might still be worth squeezing
into the qrcode? I will do some scanability tests with TV screens in
due course.

Dave - can you elaborate a bit? What are the XEP-0174-related
scenarios in which a qrcode is a sensible way for smartphones to learn
about some xmpp account's certs. I understand LAN discovery doesn't
always work, eg. when http://www.multicastdns.org/ is blocked, but I
don't know how often that's an issue.

I don't have a very worked out scenario for QR codes yet. I was
thinking of a setup scenario something like:

1. a mediacentre (say MythTV+boxee) has an associated XMPP account on
a server, and has been configured to connect as that JID and to accept
commands coming from certain other JIDs as trusted administrators
2. someone configures the system by attaching to this setup from a
plain HTML/.js Web interface (probably made in Strophe), sending
commands as an admin JID
3. they put mediacentre into 'qrcode pairing mode'
4. the mediacentre generates and displays a large QR code on screen,
which embeds an xmpp: URI, JID including resource path
5. iphone etc app can scan and capture this (you have to be quite
close to the screen, which is probably a good security characteristic)
6. iphone sends a hello message to the mediacentre via normal xmpp
server network
7. user gets news of this new JID via their HTML-based control panel
and has to tell the mediacentre whether to add the new controller to
roster, what group to put it in, etc
8. user can then control things from handheld mediacentre

(disclaimer: this is not a real protocol design, just some indicative
handwaving)

XEP-0174 discovery stuff would be somehow a parallel / alternate
story.  And I don't quite see exactly how the mediacentre's cert hash
fits in yet. I don't know really how trust should be handled in all
this. The basic ingredients are lying around on the floor!

Thanks for any help firming this up,

cheers,

Dan

Reply via email to