Service Key Discovery 1.0

[NISHITANI Masaki]

Hi all.
What concerns me these days is about secure data exchange
over OpenID for serious services and about this theme, I
came upon an specification, "secure key discovery 1.0"

For my understanding, this spec is about implementing
security framework on OpenID world and is still very draft.

Now I'd like to figure out some point I found.

- In this, the url of the public key is defined to be in the
  XRD document and entities will make another request for
  the url to retrieve the public key itself.
  This gives bad people a chance to pass off a fake key with
  poisoning the end-user's DNS. How about to put public key
  itself in the XRD or someone else the entity trusts (a
  key server)?
  The entity only has to manage SSL certificate fingerprints
  of XRD authorities or trusting key servers.

- With "secure key discovery", we do have to use
  "association" or "verification message" no longer.
  I think we can optimize OpenID protocol using digital
  signature with public keys. This can be done with
  following procedure.

  1. End-user enter its OpenID in RP site.
  2. RP resolve the id and select the user's OP.
  3. In the same time, RP retrieve the OP's public key.
  4. RP generate a challenge (maybe the user's http session
     id)
  5. RP send the id to the OP via http redirection.
  6. OP authenticate the user and sign to the challenge with
     OP's secret key.
  7. OP send the assertion including the signed challenge
     back to the RP via redirection.
  8. Now RP can verify the assertion with the signature
     using OP's public key.

  The good thing about this sequence is not only reducing
  network traffic, but this can be a solution against
  man-in-the-middle attacks, to which OpenID has principle
  vulnerability.

I think this spec can be quite useful for the next version
of OpenID protocol.
Does someone know the status of it?


=masaki