[OpenID] Signing method for XRD

[Peter Williams]

how far do folks intend to go?

I was watching the mix09 video from microsoft, in which an openid relying party happens to ping an STS to convert a subject name into a role (using the microsoft attribute/claim mapping rule system). Embodied in ACS, the STS is their multi-tenant resource STS - in the cloud (presumably engineered for stateful management of 10,000s of tenants, each with thousands of outstanding wsfed/SAML2 sessions).  Some library code implements ws-trust - as the medium to get the inbound token from IDP_OP translated into a transformed token with roles/permissions, providing developers with a simple object API rather than access to the details of the ws-trust protocol.

There seems little reason why the same RP could not be pinging a second "resource" OP using openid auth , rather than an STS via ws-trust  - particularly if its AX support has a role-mapper and permissioning engine rather than an attribute store. But presumably (i) there would be have to be "domain-delegation" from the RP to such a resource-OP allow the OP to do attribute mapping for a given subject name for which it is not the provisioning/controlling/registering/authenticating/etc authority, (ii) the OP could have to be interacting with the Resource-OP using the user's delegated name (rather than pseudonym name released by the IDP-OP).

Do folks see a role in openid land for a domain-tenant powered OP in the cloud, supporting RPs needs for transformation? where signed XRD conveys the trust between RP and resource STS/OP (rather than trust in certs as in the microsoft example of the relationship between an RP and its ACS-delivered resource STS)?


________________________________
From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of John Bradley [john.bradley at wingaa.com]
Sent: Sunday, June 14, 2009 7:50 AM
To: general at openid.net
Subject: Re: [OpenID] Signing method for XRD

Peter,

Yes some of us see the possibility of XRD as signed meta-data being a useful alternative to X.509 eventually.

If we have an signature method that supports enveloping signatures,  XRD will be more useful for those applications.

We can opt for the simplest signing, that of signing the binary representation of the XRD and keeping the signature in a detached file.
This may make life simpler for scripting languages dealing with cannonicalization  but at the cost of making it awkward to deal with in other environments where having the signature in the same document is very useful.

Full XMLDsig is ugly because of qnames and other issues.   We are proposing a constrained implementation that eliminates most of the cannonicalization complexities,  but is still compatible with existing libraries.

John B.
On 10-Jun-09, at 12:10 PM, general-request at openid.net<mailto:general-request at openid.net> wrote:

Date: Wed, 10 Jun 2009 09:10:44 -0700
From: Peter Williams <pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>>
Subject: Re: [OpenID] Signing method for XRD
To: Santosh Rajan <santrajan at gmail.com<mailto:santrajan at gmail.com>>, "general at openid.net<mailto:general at openid.net>"
<general at openid.net<mailto:general at openid.net>>
Message-ID:
<BFBC0F17A99938458360C863B716FE46398DCE8FDD at simmbox01.rapnt.com<mailto:BFBC0F17A99938458360C863B716FE46398DCE8FDD at simmbox01.rapnt.com>>
Content-Type: text/plain; charset="us-ascii"


my first reaction was ugh - xml-dsig has its own inband mechanism for referencing keying material - and here is openid/xrd doing yet another standard for verifying signatures and validating the supporting keying material (probably poorly).

My second reaction on reflection was that xml-dsig is rarely used to its full potential. Its typically used as a PKCS7 signing and sealing emulation modes, with an XML centric view of the world - with no particular benefit. But, if xml dsig fully uses its external references, and the references are to a world of XRD files which are TRUSTED to act as a key distribution mechanism, things get rather more interesting. In that world, the XRD is becoming a certificate, as we know it - and one whose format and semantics would enable it to go beyond the staid ol X.509 cert chains and benefit the full expression power of xri queries and XRI resolution.

What the X.509 v3 format work took part (divorcing asymmetric key management from dap/ldap resolution), XRI/XRD may be putting back together: query-based named-key resolution supporting trust fabric meshes.