[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xdi] Question about Trusted Resolution
Drummond, Thanks for this clarification. ~ Steve Drummond wrote: >Drummond and Gabe, > >I have a question. > >On today's XRI TC we discussed SAML trusted resolution and its relationship >to, given an i-name, discovering its public key in such a way that I can >trust the public key. > >It was suggested that it would be a smart thing for ooTao implementations >not to use SAML Trusted Resolution but to introduce a VeriSign-rooted >certificate hierarchy that parallels the XRI authority hierarchy for >delegated authorities. Each delegated authority would have its on Cert. Steve, the HTTPS cert hierarchy is not "Verisign-rooted". Verisign is the dominant provider of certs recognized by the major browsers, but the last I heard, there were roughly 100 CAs recognized by the major browsers. OoTao could use whatever set of HTTPS cert authorities that it trusted. >This may be a good mechanism to ensure that the public key I get back for >@ootao*andy is not spoofed, but I'm still using HTTPS (not SAML) Trusted >Resolution to get back the SEP URI for @ootao*andy's OpenID service (and all >other services, including something that might even be a "key service".) True. >(I'm pretty sure that Gabe brought up this same or a related point during >the call.) > >Here's the question: If I trust HTTPS Trusted Resolution to get the URI for >@ootao*andy's OpenID service, why shouldn't I trust HTTPS Trusted Resolution to get back the public key for @ootao*andy? I think the consensus on the call is that you can do just that. In other words, if you trust the full HTTPS resolution chain to the XRDS from @ootao that describes *andy, and if you trust @ootao, then you can trust @ootao to either: a) give you the public key for @ootao*andy directly in the XRDS, or b) If there is a "public key service type", then give you a service endpoint URI from which you can request the public key. Either would work and both would have the same trust model, although (b) involves one more HTTPS call, so it comes down to whether keeping the public key in the XRDS is more desirable/efficient than using a separate service to store it. =Drummond
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]