Key Discovery In DTP Draft 3

[Granqvist, Hans]

+1. A lot of thought went into the KeyInfo element design.
And the spec can define a valid subset of KeyInfos, too, if needed.


 -----Original Message-----
From: 	Recordon, David [mailto:drecordon at verisign.com]
Sent:	Friday, January 05, 2007 09:50 AM Pacific Standard Time
To:	Grant Monroe
Cc:	specs at openid.net
Subject:	RE: Key Discovery In DTP Draft 3

True, though why not still use this XML structure and the
"RetrievalMethod" element within the XRDS so that can then point to a
remote "KeyInfo" element in another XML document?

--David 

-----Original Message-----
From: grant.monroe at gmail.com [mailto:grant.monroe at gmail.com] On Behalf
Of Grant Monroe
Sent: Friday, January 05, 2007 8:31 AM
To: Recordon, David
Cc: Carl Howells; specs at openid.net
Subject: Re: Key Discovery In DTP Draft 3

On 1/4/07, Recordon, David <drecordon at verisign.com> wrote:
> Hey guys,
> Was looking at
> http://openid.net/specs/openid-service-key-discovery-1_0-01.html 
> tonight and curious why the decision was made to define the <PublicKey

> /> element which contains a link to the RSA key or X.509 certificate 
> versus embedding the key in the XRDS file?

I believe the rational was that KeyInfo objects can be quite large.
Especially if you have multiple services using them. We were concerned
about XRDSs getting really large. It doesn't make a whole lot of sense
to download a key for a service entry you aren't even interested in.

--
 Grant Monroe
 JanRain, Inc.
_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20070105/7891503f/attachment-0002.htm>