Service Key Discovery 1.0

[Hans Granqvist]

In essence, OpenID is a reaction to (perceived?) complexity, so it's an
uphill battle to reference SAML, XRI, or anything that touches on any
W3 or OASIS standard effort relating to XML and security, really.

So for OpenID, there has to be a simpler, "key/value-pair," way of
doing what's desired, it seems.

Hans

On 1/21/08, Drummond Reed <drummond.reed at cordance.net> wrote:
> Masaki, Peter has a good point -- the XRDS keyinfo discovery mechanism,
> specified in section 10.2 (SAML Trusted Resolution) of XRI Resolution 2.0
> Committee Draft 02
> (http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.pdf
> ), deals with DNS poisoning by using signed SAML assertions (including the
> ds:keyInfo element) for each authority in the resolution chain. So presuming
> HTTPS is used for the first root authority call, you should be good all the
> way down the chain as long as signatures verify.
>
> (Peter's also right that libraries have not implemented it yet, but that may
> be changing soon as demand for secure key discovery rises...)
>
> =Drummond
>
> > -----Original Message-----
> > From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
> > Of Peter Davis
> > Sent: Monday, January 21, 2008 6:33 AM
> > To: NISHITANI Masaki
> > Cc: specs at openid.net
> > Subject: Re: Service Key Discovery 1.0
> >
> > 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
> >
> > _______________________________________________
> > specs mailing list
> > specs at openid.net
> > http://openid.net/mailman/listinfo/specs
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>