No subject

Thu Jul 16 19:24:34 UTC 2009

n a UCI space of a billion (or more) people.

________________________________________
From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of =
Santosh Rajan [santrajan at gmail.com]
Sent: Sunday, July 26, 2009 7:14 PM
To: general at openid.net
Subject: Re: [OpenID] Xrd signing with username token

This is cool! Exactly what i was looking for. Now if you look at your Conte=
nt
Type definitions (comment inline)

> "application/xrd+xml;https=3Dfalse;sts-scheme=3Dnone"
> "application/xrd+xml;https=3Dfalse;sts-scheme=3Dbearer/https"
> "application/xrd+xml;https=3Dfalse;sts-scheme=3Dusernametoken/openid-asso=
ciation"
> "application/xrd+xml;https=3Dfalse;sts-scheme=3Dpki/x509cert;trustnetwork=
=3Dhttp://verisign.com/VTN"
> "application/xrd+xml;https=3Dfalse;sts-scheme=3Dpki/x509certpath;trustnet=
work=3Dhttp://verisign.com/VTN"
>

The above is scalable. That is what I meant by XMLDSig is not scalable. The
trust model is not tied to the XML itself. The trust model is external to
XML. You can add or remove trust levels without touching the XML. The RP ca=
n
request the trust level he requires. This is Terrific actually. Way to go.
Maybe we should work on this.

Peter Williams wrote:
>
> I think we have in openid everything you need, already (assuming signed
> XRDs using xmldsig markup is finally embraced by the community, much as
> disclosed in the openid auth spec).
>
> xmldsig is a type system; nothing more and nothing less. Its scalability
> as a secure type is obviously a function of the key management system one
> chooses in the xmldsig "profile". If VeriSign public certs are used in th=
e
> key management (because the XRD is signed with an xmldsig using a keyinfo
> with certs)... it scale to VeriSign cert-scale. If the keyinfo is
> alternatively a reference to usernametoken based on the OP->RP associatio=
n
> handle/secret, it has a built in scaling limit: hopefully of 2 parties.
> You "cast" the originally signed XRD base type into a subclass, whose
> additional programming suits the variant of idp discovery you conceive.
>
> My non-idea was to use openid discovery's existing request/response
> protocol for accessing XRI proxies ...to signal EXACTLY what you list
> below. Rather than view the XRI proxy as a name resolver, view it as an
> STS for RPs.
>
> I'll venture that openid has the good model already . The RP can already
> add an accept header TODAY to the http GET, when pulling the XRD. One
> example header would be : "application/xrd+xml;https=3Dfalse;saml=3Dtrue"=
.
> This asks for (i) the leaf XRD (not the XRDS), (ii) that any upstream
> communication need not necessarily be over https, and (iii) please sign
> the "XRD securitytoken" using the SAML2 variant of xmldsig. The proxy
> resolver already know how to generally search out, match and automaticall=
y
> access real responders that can satisfy such security requirements.
>
>
> "application/xrd+xml;https=3Dfalse;sts-scheme=3Dnone"
> "application/xrd+xml;https=3Dfalse;sts-scheme=3Dbearer/https"
> "application/xrd+xml;https=3Dfalse;sts-scheme=3Dusernametoken/openid-asso=
ciation"
> "application/xrd+xml;https=3Dfalse;sts-scheme=3Dpki/x509cert;trustnetwork=
=3Dhttp://verisign.com/VTN"
> "application/xrd+xml;https=3Dfalse;sts-scheme=3Dpki/x509certpath;trustnet=
work=3Dhttp://verisign.com/VTN"
>
> or, if I extend a bit
>
> "text/powder+rdf;foaf+ssl=3Dtrue;wot-scheme=3Dpgp"
>
>
> in about a days work, an ordinary programmer with no background can reduc=
e
> the client side of that to pratice, based on minor modifications to
> http://openxri.org/client.html. Just subclass ResolverFlags. My eperience=
,
> as a low-end programmer using Java, was that modify the openxri server
> logic to offer the google-like XRD signing took 2 days, given access to a
> $50 book fom the local bookshop.
> ________________________________________
> From: general-bounces at openid.net [general-bounces at openid.net] On Behalf O=
f
> Santosh Rajan [santrajan at gmail.com]
> Sent: Sunday, July 26, 2009 9:48 AM
> To: general at openid.net
> Subject: Re: [OpenID] Xrd signing with username token
>
> Interesting because I had posted a few days back my wish to see XRD with
> layers or levels of security. Something like
> XRD with no security
> XRD with SSL
> XRD signed with generated association
> XRD cert signed
> XRD cert chain signed
> I also think XMLDSig does not scale well in this kind of scenario and
> thats
> the reason we are stuck with the current security model for XRD. Maybe
> this
> is something the Crypto-XML folk need to work on.
>
>
> Peter Williams wrote:
>>
>> Interesting choice - because its the one that goes to heart of a UCI
>> control system based on idp discovery supporting the OP portability of
>> users.
>>
>> Now, the question will be: how will the OASIS folks designing XRD to be
>> signed by trusted THIRD parties now act to prevent the re-purposing and
>> re-signing of the signed XRD by fourth parties?
>>
>> Concerning the association handle/secret, I'm using the association
>> handle/secret already agreed by the standardized protocol and method.
>>
>> The point is: use the standard public system as a bootstrap into a
>> private
>> system. Use the "starter" XRD from some low-assurance source like a
>> Google
>> Apps-domain (hosted by Google cloud, now) and apply the existing
>> association ...to negotiate a new discovery point and new association at
>> a
>> higher assurance level.
>>
>> Such a system is only what folks do in military VPN land: having trust
>> overlays within trust overlays so that the complexity of navigating the
>> very trust fabric becomes part of the realtime key management for crypto=
.
>> It's only what folks do in more conventional SSLVPN tunneling, where the
>> certs used in the first handshake create a confidential channel -  over
>> which a second round of certs are then shared as a stronger basis for
>> agreeing the keys.
>>
>>
>>
>> ________________________________________
>> From: general-bounces at openid.net [general-bounces at openid.net] On Behalf
>> Of
>> Santosh Rajan [santrajan at gmail.com]
>> Sent: Sunday, July 26, 2009 5:18 AM
>> To: general at openid.net
>> Subject: Re: [OpenID] Xrd signing with username token
>>
>> 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 b=
y
>>> 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 i=
t
>>> 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 imagin=
e
>>>>>> 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-tp24632941p246641=
10.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-tp24632941p2466651=
0.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-tp24632941p24668435=
.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-userna=
me-token-tp24632941p24672646.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