[OpenID] Xrd signing with username token
Peter Williams
pwilliams at rapattoni.com
Fri Jul 24 18:14:47 UTC 2009
Precisely.
Now you have the basis for two properties: data origin authentication
to a specific audience (implied by the association handle), and the
intentional expression of a signed xrd as a control construct -a
"securitytoken" which that audience is entitled to rewrite/re-sign in
line with uci-based governance.
Let's recall the praxis of xri resolution. In practice, most rp sites
use a proxy resolver (whose model, google notwithstanding, already
addresses signed xrd about either xri or http identities). Now
envision the proxy selected by an rp being operated by the op (for
those identities it and its app domains provision, and for the
identites other providers manage when the op has suitable cross
references bridging the provider-managed namespaces). The proxy
responder rewrites the rsa/cert-signed xrd it has just sourced from
any reachable provider as a usernametoken/handle-signed securitytoken,
playing the role of a resource sts.
In a uci friendly op, rewriting would apply the rp's trust model for
root anchors. If that op is verisign, say, it's job now is to enforce
a billion trust networks, each expressed as a validation overlay -
applied during token rewriting. In practice, the op (or more likely op
(x)/rp(x) outsourcer) just ties a ctl to each association handle,
listing the self signed root anchors selected by the rp.
Eliminates:mandatory PKi support in rp systems for openid discovery,
http response signatures, dependency on "browser/os" root stores.
Facilitates: offloading trust management to op/op(x), each rp stays in
control of choice of trust anchors, namespace cross references enables
cloud provider bridging, rp retains power to choose different proxy
resolvers as it's primary reference point ... or do it's own trusted
name resolution.
Of course, this should sound like xkms/xkiss in concept - but without
the XML overhead. Rather than only tie outsourced trust management to
XML dsig reference resolution, also allow it to be tied to the
discovery handlers in openid rp's.
On Jul 24, 2009, at 1:28 AM, "Hans Granqvist" <hans at granqvist.com>
wrote:
> Isn't the handle unique per association, which means no one outside
> the association could verify the signature?
>
>
> On Thu, Jul 23, 2009 at 12:01 PM, Peter Williams<pwilliams at rapattoni.com
> > wrote:
>>
>> Rather than sign the xrd wit rsa and public cert, can we also imagine
>> signing with a username token, where the digested password is the
>> existing openid association handle for that rp?
>>
>> (username token would have STD timestamp and nonce, to address
>> replay)
>>
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>>
More information about the general
mailing list