FWIW, the XRI form of openID's provides just such a mechanism, where- by the publisher of the XRD signs all (or a part of) the XRDS, tho i know of few libraries today which support trusted resolution[1].
=peterd [1] http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0- cd-02.pdf On Jan 21, 2008, at 5:38 AM, NISHITANI Masaki wrote: > 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 > > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs