[OpenID] Xrd signing with username token

[Santosh Rajan]

Hey Peter I like the Idea.
I am not critisizing you here, what I want to tell you, is that I find it
difficult to understand what you are saying sometimes, because of the way
you write.
Does anyone else have the same problem reading Peter's writing, or is it me
only?
Peter I suggest you use shorter sentences, and take things step by step,
like you were explaining to a fifth grader.
I like the idea and want to understand this better. Thanks.

Peter Williams wrote:
> 
> 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
>>>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
> 
> 


-----

Santosh Rajan
http://santrajan.blogspot.com http://santrajan.blogspot.com 
-- 
View this message in context: http://www.nabble.com/Xrd-signing-with-username-token-tp24632941p24664110.html
Sent from the OpenID - General mailing list archive at Nabble.com.