[OpenID] Google discovery prototype: host-meta from Google

[Peter Williams]

Why NOT use XRDs themselves as the means to "manage" the trust-federations ?

Since xmldsig has a resolver, why not let its references be XRIs - where the xmldsig resolve just invokes the XRI resolver client that conforming OP/RPs already have?

If typing xmldsig validation logic to XRI validation logic is too big of a leap, we could have the signature bear a second within-document reference - to a SignaturePropery whose value bears 2 "optional-to-follow" XRI references. The first locates the authority for which there is an embedded SEP that matches the providerID of the XRD under validation (and also provides ds:keyinfo cert chain material). The second locates the authority of the providerID itself, to manage trust anchors in the x509 certification graph. (The signed XRD of a provider is basically just a CTL, if it contains a list of $certificate*($x509) elements).

If we did the latter, we are basically just borrowing established knowhow from the word of SAML1.1 tokens and ws-security . We'd be treating the XRD as a security token AND as an assertion - that its an assertion than can be queried for REAL.

Since we actually have XRI resolvers built into all RPs and OPs, this is all rather better than the SAML method - especially since its hard to find implementations of the SAML2 authnreq protocol that offer assertionquery resolution. But who cares! If one has signed XRDs and a resolver AND (custom) openid association handles, one doesn't really need SAML2's authnreq protocol or saml tokens/confirmations or SAML metadata or ws-security! Its all built into openid + signed XRDs! Now we can start applying openid to web services, not only browser handoffs!

(For W3C types: wherever you read XRD above, you can substitute FOAF file. For "XRI resolution", similar you can substitute "foaf+ssl" resolver.)
_____________________________________
___
From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of Santosh Rajan [santrajan at gmail.com]
Sent: Thursday, July 16, 2009 3:18 AM
To: general at openid.net
Subject: Re: [OpenID] Google discovery prototype: host-meta from Google

I somehow cant come to terms with this idea of coupling trust with discovery.

1) It complicates discovery.
2) "Trust" itself is a nebulous quantity. There are levels of trust. So what
level of trust are you going to go with? This will invariably lead to
disagrements. Each persons idea of trust is different. The concept of trust
has been there from the beginning of humankind. How are you going to
quantify this in the digital world?

Trust must be decoupled from discovery. We need to start with a simple basic
discovery with no trust addressed. Then we need to add layers of trust in
such a way that users and applications can pick and choose the level of
trust they need.

For eg. Discovery for logging into a blog, shopping site, or bank will be
the same. But each one requires a different level of trust.

So the kind of solution I would like to see is something like this (this is
just an example).

Layer 1. Basic Discovery Layer
Layer 2. Trust Level 1 - ssl
Layer 3. Trust Level 2 - signed XRD
Layer 4. Trust Level 3 - Signed XRD with cert chain

In such a scenario, we can have OP's who support different levels, RP's can
choose which level they require.

I have no idea how this can be done. But I am sure that we should not try to
solve all the problems at the same time. Let us come up with the Basic
Discovery Layer first. And then move upwards step by step.


SitG Admin wrote:
>
>>Let me make the point more explicit:
>
> Took me a while, but I think I'm finally beginning to get this.
> Thanks for sticking with it.
>
>>1. The design being discussed in the XRI TC allows sites to host
>>their signed XRD documents anywhere in the Internet. It uncouples
>>the trust elements of discovery from the path followed to perform
>>discovery.
>
> Discovery (via DNS, or XRI, or whatever) can thus be addressed
> separately, with keys/certs the important point on which trust rests?
>
>>2. The design being discussed at the XRI TC would allow sites to
>>delegate trust to any other site of their choice, by signing
>>delegation statements. This is necessary to really accomplish the
>>vision in (1),
>
> Delegation provided (and enforced) by signatures. Peter's concerns
> are making more sense to me too, though, now; to keep trust truly
> decoupled from the path followed, it wouldn't dictate a path for
> revocation to follow, so how *do* we make certain that our trust is
> not relying on certs that we just haven't found out yet had been
> revoked?
>
> But this is probably just me still catching up :)
>
> -Shade
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>


-----

Santosh Rajan
http://santrajan.blogspot.com http://santrajan.blogspot.com
--
View this message in context: http://www.nabble.com/Google-discovery-prototype%3A-host-meta-from-Google-tp24474276p24513788.html
Sent from the OpenID - General mailing list archive at Nabble.com.

_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general