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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grant Monroe Sent: Friday, January 05, 2007 8:31 AM To: Recordon, David Cc: Carl Howells; specs@openid.net Subject: Re: Key Discovery In DTP Draft 3 On 1/4/07, Recordon, David [EMAIL PROTECTED] 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@openid.net http://openid.net/mailman/listinfo/specs
RE: Key Discovery In DTP Draft 3
+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:[EMAIL PROTECTED] Sent: Friday, January 05, 2007 09:50 AM Pacific Standard Time To: Grant Monroe Cc: specs@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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grant Monroe Sent: Friday, January 05, 2007 8:31 AM To: Recordon, David Cc: Carl Howells; specs@openid.net Subject: Re: Key Discovery In DTP Draft 3 On 1/4/07, Recordon, David [EMAIL PROTECTED] 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@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Key Discovery In DTP Draft 3
That sounds fine. I have never heard of the RetrievalMethod element, so I can't really speak to whether that is the way to go or not. Is it part of XRDS? On 1/5/07, Recordon, David [EMAIL PROTECTED] wrote: 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grant Monroe Sent: Friday, January 05, 2007 8:31 AM To: Recordon, David Cc: Carl Howells; specs@openid.net Subject: Re: Key Discovery In DTP Draft 3 On 1/4/07, Recordon, David [EMAIL PROTECTED] 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. -- Grant Monroe JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Key Discovery In DTP Draft 3
On 1/5/07, Recordon, David [EMAIL PROTECTED] wrote: Nope, it is still part of the KeyInfo element defined at http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo. Ok. I didn't realize that functionality was already defined. I think that seems like a reasonable change. I can't say whether we would use the KeyInfo object in the same way that the SAML guys do. I think that we would just have the KeyInfo element as a child of the Service element it applies to. Drummond, can you provide a reference to the part of the specification that describes using KeyInfo in XRD? -- Grant Monroe JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Key Discovery In DTP Draft 3
Just FYI, the xmldsig KeyInfo element is already part of the XRD schema because the XRI Resolution spec uses it in the SAML form of trusted XRI resolution. And either the SAML form or the HTTPS form of XRI trusted res can give you the security characteristics in the Key Discovery spec. That said, there can be advantages to managing the cert via an independent service. So I'm not coming down on either side (yet ;-) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Thursday, January 04, 2007 10:07 PM To: Carl Howells; Grant Monroe Cc: specs@openid.net Subject: Key Discovery In DTP Draft 3 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? From the research I've done tonight, it looks like the W3C in 2002 described how to do this as part of xmldsig. Seems like we can just use the KeyInfo element. http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo They've also then recently put out a note describing the changes to that document to match XML in 2006. http://www.w3.org/TR/2006/NOTE-DSig-usage-20061220/ Is there something that I'm missing from the design standpoint as to why this wasn't done? If anything, it seems like it would reduce a fetch if the key was in the XRDS file itself. --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Key Discovery In DTP Draft 3
Oooh, interesting... So looking at working draft 10 http://www.oasis-open.org/committees/download.php/17293 it seems that 3.2.5 is most relevant in that it describes xrd:XRD/xrd:Service/ds:KeyInfo which seems to be where in the schema the key would want to sit. The only thing is that 3.2.5 is talking about having the key present to verify a signature on the XRD file itself, though in this case it may not actually be signed. What I was toying with was something along the lines of: Service Typehttp://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo/ Type ds:KeyInfo ... /ds:KeyInfo /Service Thus it makes it easy for existing Yadis libraries to pick the key out by the Type element. --David -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Thursday, January 04, 2007 10:23 PM To: Recordon, David; 'Carl Howells'; 'Grant Monroe' Cc: specs@openid.net Subject: RE: Key Discovery In DTP Draft 3 Just FYI, the xmldsig KeyInfo element is already part of the XRD schema because the XRI Resolution spec uses it in the SAML form of trusted XRI resolution. And either the SAML form or the HTTPS form of XRI trusted res can give you the security characteristics in the Key Discovery spec. That said, there can be advantages to managing the cert via an independent service. So I'm not coming down on either side (yet ;-) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Thursday, January 04, 2007 10:07 PM To: Carl Howells; Grant Monroe Cc: specs@openid.net Subject: Key Discovery In DTP Draft 3 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? From the research I've done tonight, it looks like the W3C in 2002 described how to do this as part of xmldsig. Seems like we can just use the KeyInfo element. http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo They've also then recently put out a note describing the changes to that document to match XML in 2006. http://www.w3.org/TR/2006/NOTE-DSig-usage-20061220/ Is there something that I'm missing from the design standpoint as to why this wasn't done? If anything, it seems like it would reduce a fetch if the key was in the XRDS file itself. --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Key Discovery In DTP Draft 3
That could work. Very XDI RDF-like approach, i.e., the URL/XRI being resolved is the Subject, the URL/XRI value of the Type element is the RDF predicate, and the value of the data sharing:KeyInfo element is the RDF object (in this case a literal). =Drummond -Original Message- From: Recordon, David [mailto:[EMAIL PROTECTED] Sent: Thursday, January 04, 2007 10:35 PM To: Drummond Reed; Carl Howells; Grant Monroe Cc: specs@openid.net Subject: RE: Key Discovery In DTP Draft 3 Oooh, interesting... So looking at working draft 10 http://www.oasis-open.org/committees/download.php/17293 it seems that 3.2.5 is most relevant in that it describes xrd:XRD/xrd:Service/ds:KeyInfo which seems to be where in the schema the key would want to sit. The only thing is that 3.2.5 is talking about having the key present to verify a signature on the XRD file itself, though in this case it may not actually be signed. What I was toying with was something along the lines of: Service Typehttp://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo/ Type ds:KeyInfo ... /ds:KeyInfo /Service Thus it makes it easy for existing Yadis libraries to pick the key out by the Type element. --David -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Thursday, January 04, 2007 10:23 PM To: Recordon, David; 'Carl Howells'; 'Grant Monroe' Cc: specs@openid.net Subject: RE: Key Discovery In DTP Draft 3 Just FYI, the xmldsig KeyInfo element is already part of the XRD schema because the XRI Resolution spec uses it in the SAML form of trusted XRI resolution. And either the SAML form or the HTTPS form of XRI trusted res can give you the security characteristics in the Key Discovery spec. That said, there can be advantages to managing the cert via an independent service. So I'm not coming down on either side (yet ;-) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Thursday, January 04, 2007 10:07 PM To: Carl Howells; Grant Monroe Cc: specs@openid.net Subject: Key Discovery In DTP Draft 3 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? From the research I've done tonight, it looks like the W3C in 2002 described how to do this as part of xmldsig. Seems like we can just use the KeyInfo element. http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-KeyInfo They've also then recently put out a note describing the changes to that document to match XML in 2006. http://www.w3.org/TR/2006/NOTE-DSig-usage-20061220/ Is there something that I'm missing from the design standpoint as to why this wasn't done? If anything, it seems like it would reduce a fetch if the key was in the XRDS file itself. --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
