[OpenID] Xrd signing with username token

[Santosh Rajan]

The notion of a signed XRD being a security token. Is the association
generated on the fly, like OpenID? How will it work?


Peter Williams wrote:
> 
> 
> Hey Santosh
> 
> But you dont say what it is that you like!
> 
> Is it the billion trust models?
> 
> Is it the outsourcing of cert chain validation to the resolver hosted by
> the OP?
> 
> Is it the notion of a signed XRD being a securitytoken?
> 
> Is it the translation of one securitytoken into another,doing
> role/privilege mapping like a resource-STS?
> 
> 
> 
> 
> ________________________________________
> From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of
> Santosh Rajan [santrajan at gmail.com]
> Sent: Saturday, July 25, 2009 10:20 PM
> To: general at openid.net
> Subject: Re: [OpenID] Xrd signing with username token
> 
> 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.
> 
> _______________________________________________
> 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-tp24632941p24666510.html
Sent from the OpenID - General mailing list archive at Nabble.com.