[OpenID] providerID and keyinfo; trust elements used in the SEPs of XRD files

[Peter Williams]

Some fun when thinking about XRI and signed XRD. Delete now, if your tolerance for email is ~50 words.

-----------

Remembering that xmldsig's keyinfo -- as a type -- doesn't have to refer to a public key chain, we might consider what happens if the keyinfo in the SEP elements of an XRD is specifically a "derivedkey".

Now, what would such keyinfo mean, in the context of an SEP?  From what is it the key "derived"? How can it be applied in the next generation of openid infrastructure?

And specifically: What might be the relationship to the current discussions concerning "signed XRD"?

Reading the description of an XRD's "trust element" FOR SEPs - as described in XRI Resolution v2 document -  *service* elements may leverage "trust elements" to help describe how (service) "target resources" trust -- and may be trusted. The 2 trust elements are:- providerID and keyinfo. Though these fields may be used to orchestrate XRI's own trusted Resolution mode (to address trusted delegated for resolution of XRIs subspaces ), they do not seem limited to this role. They appear to be just as applicable to non XRI-resolving applications -- simpler "XRD/XRDS Applications" like YADIS that are only interested in SEPs vs XRI resolution. In that simpler world, the trust element fields  appear to lose none of their semantics, however. The field of applicability is merely now an "external" trust fabric, rather than the trust fabric built into the (unused) XRI Authority resolution.

Hopefully, Im not misreading the specification on XRD, as I uncoupleXRD's trust fabric support from native XRI resolution.

So, given that assumption:-

I can now opt, as an RP, to act as a parent authority. That is, For each of my web service resources, I can describe the resource using an XRD service element - whose parent authority is obviously the RP/SP (vs the OP). By running a walled garden "community" root, the RP's XRD server would seem to enable the RP to mint and publish SEP for each such web service; and, attach trust elements for use by those within the walled garden. One would first attach the providerID - as the indication that particular trust fabrics "are indeed available" for use by authorized XRD consumers. (This is essentially a hint of requirements for walking the external trust fabric.) Second, attach a keyinfo trust element, that refers to a derived key that is - perhaps - derived from kerberos tickets or ws-sx session. (Derivation and proven use of keys sould (just like the SSL closure protocol) provides actual evidence - that an actual OP->RP->SP communications run is compliance with the providerID's associated trust policy.)

So, assuming I geberallty comprehend the design of the "trust meta-model" in XRD land and am not abusing cmldsig's derivedKey notions, an XRD describing a target resource called helloworld (locating a WSF endpoint set, and ws-policy file, say) would have as its XRD query field something like

(ldaps://rp.domain.com/ou=policyregion)*helloworld

where

- the ldaps URI is the community root domain

- the SEP bound to helloworld publishes the service types (e.g. its a wcf service), and locates the usual set of endpoints for service delivery, ws-policy metadata, etc.

- the ou=policyregime might allow the controls expressed by the root domain/community to be augmented by a "group policy" management overlay - that provides for fine-grain policy role and permission controls

- the rp.domain.com is itself a DNS-domain in a federation-of-domains directory-type environment, whose directory service agents have kerberos KDCs attached (as in MSFT Active Directory, or Novell NDS)

- DNS would not only host site-specific locators for the ldap servers but would host similar SRV locators for the XRD servers for the community name space, allowing for classical multi-mastering and all the usual DR (disaster recovery) based fallback or remoting

- DNS would similarly host kerberos kdc locator records for KDCs co-resident with the XRD servers (rather than the ldap servers)

- XRI canonicalID and canonicalEquivID synonyms  for XRI Authorities (not SEPs) might represent the actual trust-partnerships between OPs and an a set of RP services distributing metadata using an XRI community.

- a particular scheme for managing authority synonyms might or might NOT allow for transitive trust down and amongst linked (RP) subspaces, or control delegation/impersonation rights from services to other services described by the (linked) RP naming segments under a community root

Now, if one is doing the kind of thing described above, I can see XRI and XRD being a major hit in UCI world. We WOULD have broken free of hub/spoke and other iIDP/OP-centric trust fabrics.

-------

Such a world seems a very "practical way" to augment what XRDs do: adding trust and locator issues for walled garden communities. And it would seem to be doing this in a manner similar to what microsoft did with X.500 name resolution when fashioning ActiveDirectory: removing from X.500/ldap its former-association as an unweb, "evil" global name infrastructure (the kind which W3C founders abhor). It would seem to suit the location of trust fabrics for RDF-based SPARQL services just as well as it would suit XML-based web services, furthermore.

Having now studied the XRI resolution specs for my third time (in 3 years) trying really to understand openid and its potential, I really don't think any of the above is in any way inconsistent with XRD goals. Though openid has focused on applying XRD to openid-delegation and identity authorities, its pretty clear to me (given the ws-trust references in the discussion of the rationales for synonyms) that the architects intended synonyms, redirects, refs and persistentID to be applied by resource "authorities" consuming assertions.