RE: [xdi] Question about Trusted Resolution

["Steven Churchill" <steven.churchill@xdi.org>]

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