[OpenID] Signing method for XRD

Tue Jun 16 17:29:33 UTC 2009

I like the fact that signed XRD seems to providing richer opportunities for openid. Its less and less just a one stop solution (a poor man's SAML2). Rather, openid/oauth really is a toolkit - from which one builds "secure social media".

One *could* think of a signed XRD as a container for an infocard descriptor, but that was not where I was going. (*)

In YADIS vs XRI land, we could view a signed XRD as a simple "set of instructions from the user" - augmenting the control properties of the openid delegation flow. Obviously, control is exercised by users only when its the user who signs (or countersigns) the XRD - rather than a TTP authority.

So, now lets work through the flow.

lets say the RP has already received a google assertion, with its trademark "directed id" form for the asserted subject name - because of the RP's earlier invocation of the directed identity flow at the Google Accounts OP.

However, the user had invoked openid-delegation at that RP. This means that the primary key is not controlled by the OP The primary key is either the openid-delegation URL or the canonical-ID of the XRI used for openid-delegation. (I can be corrected here, for none of this is discussed clearly in actual specs.)

Before "fully consuming" the assertion, lets imagine that the RP and the new "resource-OP" entity (operated by Rapattoni.com say)  have existing association handles. IE. there is no role for signed XRD in association crypto/keymanagement; its only role is control.

Seeing as its all there is, RP must invoke a run of openid auth v2 addressing the resource-OP, doing so according to (new) user requirements expressed in the signed XRD. these address the OP, and provide requirements to that OP.

To request the resource-OP to engage now in non-classical/deviant behavior, openid auth run invokes an identity-less transaction, indicating that NO user auth is requested; and perhaps an AX-like extension is used to best signal these constraints. However, per identityless-transactions rules, only 1 (and never 2) of the openid/identity fields are populated with the delegated URL/XRI (or the delegated URL/XRI goes in an extension field).

Skipping (not a pun, honestly) the user auth and release controls stage, the OP invokes its AX handlers to "transform claims " - transforming the delegation URL/XRI into a set of roles and/or action permissions possibly based on attributes derived from the token supplied earlier by Google Accounts OP.

The right of the resource-OP to perform this identity-less mode/extension is, let's say, signaled by the user's XRD. Given the proposed mode, and given receipt of a proposed delegated URL/XRI, the OP can retrieve the signed XRD to "learn" requirements. Normal PKI ( or kerberos) allows the OP to verify the signature.

In such a world, the signed XRD really is just another link in its own signature+CertChain  metadata, acting as a container for control bits targeting (resource) OPs much as the other X.509 formatted certs in the chain act as a container for various key usage bits and extended usage flag targeting end-systems/cryptomodules. The XRD is just a bit more flexible as a format than the X.509 Certificate format.

Now, If one was to add a little bit of Rivest's SDSI scheme into the mix, the signed XRD might even express - in some suitable algebra - the transformation rules that the resource-OP is to use.

I'm not really proposing any of this this. Im simply using it as a thought experiment to understand the semantics folks are intending for thened XRD concept. It just  happens to do whatever microsoft were doing in their mix09 openid demo applying an the ws-trust/STS now with (slightly enhanced) openid middleware. It seemed a litte silly to do a run of openid auth, and then tag on the end a stateless use of ws-trust - having a hosted STS do remoted claims transformation. Why not have openid apparatus do the same, leveraging the identity-less framework and the new control structures afforded by a user-signed XRD ?

OK. Now peter has homework to do: understand John's idea that the openid/oauth hybrid can do better than the above, by specifically exploiting the oauth control plane. I think now using Andrew's .NET library is going to help out, since its offers the hybrid control plane. The trick is going to be not to lose what pure openid-delegation brings in the UCI model - user freedom/portability from OP governance (over identities, or per-RP authorization logics)

(*) The mix09 presentation I viewed opened by making the case for infocards and identity selectors, described various protocol flows talking to a resources STS supporting openid or WCF services  with federated bindins support, but then didn't close by saying infocards are the final sauce that makes it all hold together... . However, I for one _can_ imagine, when XRI Resolution is generating [signed] XRDs, that different QXRI paths would each identify a different infocard descriptor ...to be placed in the dynamically-signed XRD resulting from the XRI query. As you roam, there is a place where your secure desktop can learn your card set's  metadatas, then).

________________________________________
From: John Bradley [john.bradley at wingaa.com]
Sent: Tuesday, June 16, 2009 4:52 AM
To: Peter Williams
Cc: general at openid.net
Subject: Re: [OpenID] Signing method for XRD

Peter,

The Resource or RP/STS is part of the RP's trust domain not the users,
or the OP's in IMI (the protocol formerly known as infocard) or WS-Fed.

I think you are proposing the user having a second Resource OP that is
delegated to from the users XRD.

That is possible but the second OP will still ned to authenticate the
user in some way.

In the WS-Fed case the RP asks the RP/STS for a token and the RP/STS
asks the user to select a card that gets a token from the users IP/STS.
The sequence unwinds in reverse order for the reply.    This can work
because the RP and RP/STS have pre established trust.

I suspect oAuth might be more appropriate for this second OP than
openID.

If I remember correctly Sxip's protocol supported something like what
you are proposing.

John B.

On 16-Jun-09, at 6:03 AM, Peter Williams wrote:

> 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.
>
>