[OpenID] using kerberos trust mediation, and binarysecurity tokens from securitytokenreferences in the keyinfo

[Peter Williams]

"it can be used for both RPs and OPs."

1. Given the architecure is general, and signed XRD is only an embodiment, I dont see why another vendor (e.g. microsoft) could not adopt the same basic markitecture and sign a ws-addressing formatted file rather than an XRD, and be distributing it using a similary n-level set of  indirections based on lgc/ldap/ADAM resolvers (vs XRI-style resolvers/forwarders/redirectors). In that way, the activedirectory kerberos-federations could be brought to bear, in the xmldsigs (rather or as an alternative to trust models enforced using certs)

Given the XRI TC is unlikely to generalize beyond its own special constructs (XRD), perhaps the openid discovery wg would be more scope to be more general -- and ensure openid's use of secure web discovery its not tied to signed XRD embodiment (particularly if IPR issues get nasty).

2. i generalized the signing support in some extensions to the openxri server so now it will sign at the XRDS level, aping the google example.  It will now generate and bear 1 or more xmldsigs, over one or more (optionally-signed) XRDs in the XRDS. It will do this on the fly for any XRDS its proxy client has resolved as a part of XRI auth-res, including re-signing those XRDS provided formally by other providers. Formally, this is what NIST would call a key-translation service, for bridging key management domains.

http://yorkporc.spaces.live.com/blog/cns!5061D4609325B60!477.entry for a PDU dump.

3. Rather than have certs directly expressed in the keyinfo, I think folks should reference a securitytokenreference, that points to a binary security token that FORMALLY represents a certPath typed value (not just a collection of certs). In this way, the semantics of cert chaining are explicit, and folks know how to properly validate the cert chain (using OCSP, CRLs, CTLs, ...).

if one does this, the binary securty token can also then be a non certPath, such as a kerberos ticket , with little change to the software. This would enable a common formatting library to also leverage activedirectory-based trust federations when securing all the various locator/forwarding/redirecting signals.

I'll try this kerberos experiment today against an win2008 EE kerboeros KDC, seeing if this transitive-trust networking across delegated child domain-names  in a directory _forest_ (or multi-forest)  is a viable alternative to PKI-based delegation. I think I have enough personal skill and knowhow at this this point, in Java., to at least get the kerbersos service ticket.
________________________________
From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of Breno de Medeiros [breno at google.com]
Sent: Wednesday, July 15, 2009 9:32 AM
To: Manger, James H
Cc: general at openid.net
Subject: Re: [OpenID] Google discovery prototype: host-meta from Google

Let me make the point more explicit:

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. This adds a lot of flexibility. It can be used for both RPs and OPs.