Service Key Discovery 1.0

[Peter Davis]

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 at openid.net
> http://openid.net/mailman/listinfo/specs