Subject: [KEYPROV] Browser invocation in other standards (Information Cards)

From: Anders Rundgren <[email-masked]>
Date: Sun, 30 May 2010 11:13:51 +0200

In case you thought this is a deal done, read and weep:

http://lists.oasis-open.org/archives/imi/201005/msg00020.html

  "4. Cloud and mobile selector indicators
   Object tags not available on iPhone/Android, there is an alternate 
intention URI used
   Intention URIs have a common subset, but they are not the same across 
platforms
   Need common scheme for invoking selectors
   Anticipate future submission in this area"

IMO protocols like DSKPP and KeyGen2 could very well use the same invocation
scheme as Information Card selectors.

So it is [still] up to grabbers specifying a universal mechanism that 
shouldn't
be based on HTML page embedding, since both Information Card selection
and DSKPP/KeyGen2 protocol execution is preferably performed in a for the
actual purpose adapted dialog box, rather than being a part of an arbitrary
web page.

Spawning of the mentioned mechanism is an entirely different thing which 
indeed
is usually done from an HTML page.

FWIW, I'm preparing a simplified version of the scheme I once posted in 
this list.
It is derived from recent work in Mozilla labs so it is hopefully 
implementable as well :-)

The short version of the spec is:

- Add an X HTTP header holding the name-space of the actual plugin 
(executor) like:
    X-Browser-Extension-One: urn:ietf:params:xml:ns:keyprov:dskpp

- Define a new static MIME-type specifying that we are are dealing with 
a general
  purpose extension mechanism

A plugin executor registers itself to the generic handler and its 
name-space may
be discoverable by a service provider from JavaScript unless it has been 
declared
as "restricted".

Anders