[OpenID] general Digest, Vol 34, Issue 54

Sun Jun 21 20:07:51 UTC 2009

Nerozumiem reči vašej keby ste mi posielali správi v mojom jazyku som
začiatočňík na počítači aj na internete Dakujem za porozumenie

2009/6/21 <general-request at openid.net>

> Send general mailing list submissions to
>        general at openid.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://openid.net/mailman/listinfo/general
> or, via email, send a message with subject or body 'help' to
>        general-request at openid.net
>
> You can reach the person managing the list at
>        general-owner at openid.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of general digest..."
>
> Today's Topics:
>
>   1.  providerID and keyinfo;  trust elements used in the SEPs of
>      XRD files (Peter Williams)
>
>
> ---------- Správa poslaná ďalej ----------
> From: Peter Williams <pwilliams at rapattoni.com>
> To: "general at openid.net" <general at openid.net>
> Date: Sat, 20 Jun 2009 14:18:01 -0700
> Subject: [OpenID] providerID and keyinfo; trust elements used in the SEPs
> of XRD files
> 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<http://rp.domain.com/ou=policyregion%29*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.
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090621/ce35319a/attachment.htm>